пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ
Слишком длинный поисковый запрос.
По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В системах Linux и Unix программные прерывания осуществляются черед сигналы. Существует достаточно большое количество различных сигналов Linux, но есть несколько, которые я бы выделил, поскольку очень важно знать и понимать, как они работают. К этим сигналам относятся SIGINT, SIGTERM и SIGKILL. Давайте посмотрим, что они из себя представляют.
Что такое сигнал Linux?
Мы все прекрасно знаем, что если на светофоре загорается красный свет, то пешеходы должны закончить переходить дорогу, а машины остановиться. Тоже самое и в системах Linux и Unix. Вы можете передать запущенной программе или службе некий сигнал, и таким образом с ней взаимодействовать. Например, вы можете подать программе сигнал
SIGTERM
, тем самым сообщив о том, что «загорелся красный сигнал светофора».
Конечно, пешеходы могут продолжить переходить дорогу на красный свет, или машины могут продолжать ехать, но это может быть не очень безопасно для всех участников дорожного движения. Тоже касается и сигнала
SIGTERM
, который мы отправляем процессору – процесс/программа может просто проигнорировать этот сигнал.
У каждого основного сигнала Linux есть свой номер (1-30+). Как правило, через какое-то время опытный пользователь Linux запоминает некоторые из них. Например, сигнал
SIGTERM
соответствует номеру 15. А вот сигнал под номером 9 (
SIGKILL
), вполне вероятно, знают практически все, так как с его помощью можно принудительно завершить процесс, тогда как в нашем примере с «красным сигналом»
SIGTERM
этого сделать нельзя.
На этой картинке вы можете видеть главный экран
htop
. Эту довольно удобную утилиту можно установить с помощью команды
sudo apt install htop
в Ubuntu/Mint или с помощью команды
sudo yum install htop
в RedHat/Centos/Fedora. На этом экране есть ряд сигналов завершения и многих других. Вы можете передать процессу, который вы выберите справа, любой из этих сигналов. Для того, чтобы выбрать процесс, перемещайте курсор вверх/вниз, после чего вы можете отправить сигнал, нажав F9.
SIGKILL и SIGTERM
Эти названия могут вам показаться немного жутковатыми, но, в конце концов, весь этот профессиональный жаргон Linux предназначен для того, чтобы «убивать» процессы. В основном сигнал
-9
(
SIGKILL
) нужен только в тех случаях, когда процесс/программа зависает. Стоит отметить, что такие слова, как «программа» и «процесс», являются взаимозаменяемыми в данном контексте. По сути, процесс – это любая запущенная программа (или служба), которой был присвоен PID (Process IDentifier – идентификатор процесса).
Давайте рассмотрим пример, в котором мы попробуем завершить запущенный фоновый процесс с помощью сигнала
SIGKILL
. Имейте в виду, что сигнал
SIGKILL
довольно разрушительный. Он завершит процесс в любом случае вне зависимости от того, что процесс собирался сделать с этим сигналом. Процесс может перехватывать или перенаправлять некоторые сигналы, но не все.
Здесь мы запустили процесс
sleep 1800
в фоновом режиме. Для этого в конце команды мы добавили символ
&
. Этот процесс стал первым (
[1]
) фоновым процессом с PID
574660
. После чего мы «убили» этот фоновый процесс с помощью команды
kill -9 574660
, где
-9
означает
SIGKILL
.
Несмотря на то, что процесс был завершен сразу же, мы не видим сообщения о завершении (о том, что фоновый процесс под номером 1 «убит», т.е.
[1]+ Killed
). Это произошло, поскольку ввод командной строки появился до того, как сообщение успело отобразиться, то есть операция по возвращению командной строки, оказалась более быстрой, чем операция по завершению процесса.
Мы проверяем список процессов с помощью команды
ps -ef | grep 574660
. Мы видим некоторый вывод, который относится к команде
grep
, которую мы запустили. И также мы видим, что процесс
sleep
уже завершен.
Давайте понаблюдаем за тем же процессом, но здесь мы уже будем использовать
SIGTERM
. Введем команду
kill -15 ${PID}
, где
${PID}
- это процесс, который мы хотим завершить.
Для того, чтоб вызвать/показать сообщение о завершении, мы нажали Enter (см. выше). Мы видим, что программа, как и в прошлый раз, завершилась корректно. Но на этот раз процесс внутри кода программы
sleep
был не совсем таким же, хотя в данном конкретном примере этого не видно (читайте дальше!).
В данном случае (когда для того, чтобы завершить процесс, мы использовали сигнал
-15
, т.е.
SIGTERM
) процесс
sleep
был уведомлен и смог на внутреннем уровне обработать этот сигнал. После обработки он мог завершиться самостоятельно, проигнорировать этот сигнал или ответить любым другим действием, которое было описано в коде. Мы можем убедиться в этом, если проверим выходной сигнал и/или вывод:
Здесь мы запустили процесс
sleep 2000
дважды. Для каждого запуска, чтобы завершить процесс, мы использовать разные оболочки/сеансы терминала. В первый раз для того, чтобы остановить процесс
sleep
мы использовали
kill -9
, а во второй -
kill -15
.
Мы сразу можем заметить, что в первом примере возвращается
Killed
(после команды
kill -9
), то есть процесс был «убит», а во втором -
Terminated
(после команды
kill -15
), то есть процесс завершился самостоятельно. После чего мы проверили коды завершения и увидели, что они разные.
Почему это так важно? В данном случае мы завершали простую команду
sleep
, а что если бы это была более масштабная программа? В нашем примере не происходило ничего серьезного, то есть данные не обрабатывались, трафик не пересылался туда/обратно и т.д. Но что будет, если мы отправим команду
kill -9
на наш сервер базы данных (для этого, по большому счету, необходимы привилегии root/sudo)?
Это приведет к тому, что при следующем запуске базы данных она перейдет в режим аварийного восстановления. А все потому, то для программного обеспечения эта выглядит так: «там что-то было», а теперь здесь «ничего». Иными словами, произойдет сбой. А если бы мы ввели команду
kill -15
, то программное обеспечение базы данных могло бы выполнить контролируемое завершение, то есть сначала оно могло бы заблокировать подключение новых пользователей, затем отключить/завершить сеансы текущих пользователей, после чего закончить запись данных и т.д. и, наконец, самостоятельно завершиться.
Как можно отправлять сигналы с помощью клавиатурных последовательностей?
А вы знаете, что каждый раз, когда вы отправляете запущенной программе последовательность клавиш
CTRL+c
, то вместо этого отправляется сигнал
SIGINT
? Давайте вернемся к нашему процессу
sleep
и проверим это:
Мы снова запустили процесс
sleep
, после чего нажали комбинацию клавиш
CTRL+c
. Процесс завершился, точнее,
был прерван
сигналом
SIGINT
, который мы отправили. Мы запрашиваем код завершения и вновь видим, что этот код отличается от предыдущих.
У каждого сигнала, который вы отправляете, есть свой код завершения (хотя, возможно, это касается не всех). Иными словами, когда вы используете в командной строке комбинацию клавиш
CTRL+c
, то у вас всегда будет код завершения
130
, если вы будете «убивать» процесс с помощью команды
kill -9
, то код завершения будет
137
, а если вы завершите процесс с помощью команды
kill -15
, то код завершения будет
143
.
Вы можете проверить код завершения, запросив переменную
$?
(пока вы не запустили новый процесс). Эта переменная содержит код завершения предыдущего процесса. Если вы будете знать код завершения какого-то конкретного процесса в конкретной ситуации и/или при отправке ему определенного сигнала, то это может помочь вам создать сценарии, которые будут обрабатывать другие процессы (это больше аргумент в пользу сценариев оболочки, особенно когда речь идет об управлении серверами или об автоматизированных средах).
Есть еще одна не менее популярная комбинация клавиш -
CTRL+z
. С ее помощью вы можете отправить сигнал приостановки
SIGTSTP
. При отправке этого сигнала, процесс будет немедленно приостановлен до тех пор, пока вы (например) не введете для того же процесса команду
'fg'
. Эта команда снова запустит процесс.
Подытожим
В этой статье мы с вами рассмотрели самые важные сигналы Linux, а также то, как их можно применять в средах Linux и Unix. Знание этих сигналов может помочь вам использовать и управлять Linux на повседневной основе. Например, у вас завис какой-то процесс, тогда вы можете завершить его с помощью команды
kill -9
.
Начиная с Windows Server 2012 R2 в Hyper-v появились машины второго поколения. Они добавляют некоторые преимущества по сравнению с виртуальными машинами первого поколения, поэтому следует подумать о переходе. Хотя автоматического преобразования не существует, есть способ избежать новой установки и настройки виртуальной машины.
Есть несколько причин, по которым рабочие системы до сих пор работают на виртуальных машинах первого поколения. Часто они существуют уже несколько лет и были созданы в версии Hyper-V, которая поддерживает только виртуальные машины 1-го поколения. Их по-прежнему можно использовать в более новой версии гипервизора, и они полностью поддерживаются.
И наоборот, также возможно, что версия Windows была изначально установлена на виртуальной машине, которая поддерживает только виртуальные машины 1-го поколения. Гостевая ОС, возможно, за это время была обновлена, но функции 2-го поколения в старой виртуальной машине заблокированы.
Может случиться и так, что Gen 1 будет случайно выбран при создании виртуальной машины, поскольку это по-прежнему выбирается по умолчанию в диспетчере Hyper-V.
Преимущества 2 поколения
Одним из наиболее важных преимуществ новых виртуальных машин является более высокая производительность, поскольку гостевая ОС «знает», что она работает на гипервизоре, и, следовательно, не требует эмуляции оборудования. Виртуальные машины второго поколения обладают поддержкой UEFI, работают под управлением только 64-разрядной гостевой ОС, могут загружаться с виртуального контроллера SCSI. Подключенные к контроллеру виртуальные жесткие диски можно добавлять, удалять и изменять их размер во время работы. Сетевые адаптеры также могут быть добавлены во время работы системы.
Если вы хотите настроить виртуальную машину с UEFI, вы можете сделать это только с виртуальной машиной поколения 2, т.е. безопасная загрузка доступна только в ней. Виртуальные машины поколения 1 поддерживают только BIOS и, следовательно, ограничены структурой MBR дисков и это основное препятствие при миграции.
Поиск старых виртуальных машин
Первым шагом будет обзор того, какие виртуальные машины относятся к Gen 1 (Поколение 1). С помощью PowerShell это относительно легко узнать:
Get-VM | select vmname, generation
Эта команда выведет вам список всех виртуальных машин на локальном хосте, их имена и поколение.
По сути, теперь вы можете приступить к преобразованию старых виртуальных машин. Однако это невозможно, если гостевая ОС старше Windows Server 2012 R2 или имеет 32-разрядную версию.
Следовательно, вам необходимо выяснить, какая ОС установлена на виртуальной машине. Это можно относительно легко определить через PowerShell:
Get-ComputerInfo -Property WindowsProductName, OsArchitecture
Изменение таблицы разделов на GPT
После того как вы определили, какие виртуальные машины подходят для преобразования, вам следует сначала обновить гостевую ОС до версии Windows, которую вы запланировали для новой среды.
Затем преобразовать системный диск в GPT. Начиная с Windows 10 1703, Microsoft предоставляет для этой цели MBR2GPT.exe. Программа запускается на рабочей системе со следующими параметрами:
mbr2gpt.exe /convert /allowFullOS
Утилита находится в %SystemRoot%system32 и может быть легко скопирована на другие компьютеры, если ее там нет. Это относится, например, и к серверам Windows.
Однако в случае более старых версий ОС Microsoft рекомендует выключить виртуальную машину, загрузиться в среду предустановки Windows и начать преобразование в GPT оттуда. Тогда команда выглядит немного иначе:
mbr2gpt.exe /convert /disk:<disknumber>
Номера дисков можно посмотреть программой diskpart с помощью:
list disk
Перенос виртуального диска на новую виртуальную машину
Поскольку преобразовать виртуальную машину поколения 1 в поколение 2 невозможно, теперь необходимо создать новую виртуальную машину Gen 2 и подключить к ней виртуальный жесткий диск.
Одним из побочных эффектов этого действия является то, что оно также поднимает версию виртуальной машины до текущего уровня. Это необходимо, чтобы воспользоваться преимуществами новых функций Hyper-V, доступных в Server 2016 или 2019. Новая виртуальная машина больше не будет работать на более старом гипервизоре.
Графовые базы данных (Graph databases) – это нереляционные системы (NoSQL), которые определяют корреляции между сложно взаимосвязанными сущностями. Такая структура позволяет обойти ограничения реляционных БД и уделяет больше внимания отношениям между данными.
Графовая база данных позволяет аккуратно определять взаимосвязи и дает ответы на сложные вопросы о том, как точки данных соотносятся друг с другом.
В данной статье объясняется, что такое графовые базы данных, и как они работают. Но для начала можно быстро познакомиться с другими видами NoSQL.
Что такое графовая база данных?
Графовая база данных – это нереляционный тип баз данных, основанный на топографической структуре сети. Идея этой БД восходит к математической теории графов. Графы представляют наборы данных в виде узлов, ребер и свойств.
Узлы, или точки (nodes) – это экземпляры или сущности данных; ими является любой объект, который вы планируете отслеживать. Например, люди, заказчики, подразделения и т.д.
Ребра, или линии (edges) – это важнейшие концепции в графовых БД. Они отображают взаимосвязь между узлами. Эти связи имеют направление и могут быть одно- или двунаправленными.
Свойства (properties) содержат описательную информацию, связанную с узлами. В некоторых случаях свойства бывают и у ребер.
Узлы с пояснительными свойствами создают взаимосвязи, представленные через ребра.
Графовые БД предлагают концептуальное представление данных, тесно связанных с реальным миром. Моделировать сложные связи гораздо проще, поскольку отношениям между точками данных уделяется такое же внимание, как и самим данным.
Сравнение графовых и реляционных баз данных
Графовые БД не создавались для замены реляционных БД. Стандартом отрасли на текущий момент считаются реляционные БД. Но перед этим важно понять, что может предложить та или иная разновидность систем.
Реляционные базы данных обеспечивают структурированный подход к данным, а графовые БД считают более гибкими и ориентированы на быстрое понимание взаимосвязей между данными.
Графовые и реляционные БД имеют свою область применения. Сложные взаимосвязи лучше реализовать через графовые БД, поскольку их возможности превосходят традиционные реляционные СУБД. При создании моделей баз данных в реляционных системах MySQL или PostgreSQL требуется тщательное планирование, а в графовых используется более естественный и гибкий подход к данным.
В таблице ниже приведены ключевые отличия между графовыми и реляционными БД:
Тип
Графовые БД
Реляционные БД
Формат
Узлы и ребра со свойствами
Таблицы со строками и столбцами
Связи
Представлены в виде ребер между узлами
Создаются с помощью внешних ключей между таблицами
Гибкость
Гибкие
Жестко заданные
Сложные запросы
Быстрые и отзывчивые
Необходимы сложные соединения
Варианты использования
Системы с взаимосвязанными зависимостями
Системы с транзакциями и более простыми отношениями
Как работают графовые базы данных?
Графовые базы данных одинаково относятся к данным и взаимосвязям между ними. Связанные узлы физически связываются, и эта связь рассматривается как часть данных.
При таком моделировании данных вы можете запрашивать взаимосвязи также, как и сами данные. Вместо вычисления и запросов на подключение, графовые БД считывают взаимосвязи напрямую из хранилища.
По гибкости, производительности и адаптивности графовые БД близки к другим нереляционным моделям данных. В них, как и в других нереляционных БД, отсутствуют схемы, что делает данную модель гибкой и легко изменяемой.
Примеры использования графовых баз данных
Есть много примеров, когда графовые БД превосходят все прочие методы моделирования данных. Среди таких примеров можно выделить:
Рекомендательные сервисы в режиме реального времени. Динамичные рекомендации по продуктам и электронным товарам улучшают пользовательский опыт и максимизируют прибыль. Из известных компаний можно упомянуть Netflix, eBay и Walmart.
Управление основными данными. Привязка всех данных к одной общей точке обеспечивает постоянство и точность данных. Управление основными данными крайне важно для крупномасштабных компаний мирового уровня.
GDPR и соблюдение нормативных требований. С графами гораздо проще управлять безопасностью и отслеживать перемещение данных. Базы данных снижают вероятность утечки информации и обеспечивают большую согласованность при удалении данных, чем повышается общее доверие к конфиденциальной информации.
Управление цифровыми ресурсами. Объем цифрового контента просто огромен и постоянно растет. Графовые БД предлагают масштабируемую и простую модель данных, позволяющую отслеживать цифровые ресурсы: документы, расчеты, контракты и т.д.
Контекстно-зависимые сервисы. Графы помогают в предоставлении сервисов, приближенных к актуальным характеристиками мира. Будь то предупреждения о стихийных бедствиях, информация о пробках или рекомендации по товарам для конкретного местоположения, – графовые базы данных предлагают логическое решение для реальных обстоятельств.
Выявление мошенничества. Поиск подозрительных закономерностей и раскрытие мошеннических платежных схем выполняется в режиме реального времени. Выявление и изоляция частей графа позволяет быстрее обнаружить мошенническое поведение.
Семантический поиск. Обработка естественного языка бывает неоднозначной. Семантический поиск помогает определить значение ключевых слов и выдает более подходящие варианты, которые, в свою очередь проще отобразить с помощью графовых БД.
Сетевое управление. Сети – это не что иное, как связанные графы. Графовые БД снижают время, необходимое для оповещения сетевого администратора о проблемах в сети.
Маршрутизация. Информация передается по сети за счет поиска оптимальных маршрутов, и это делает графовые БД идеальным вариантом для маршрутизации.
Какие есть известные графовые базы данных?
С ростом больших данных и аналитики в соцсетях популярность графовых БД возрастает. Моделирование графов поддерживает множество многомодельных БД. Кроме того, доступно много нативных графовых БД.
JanusGraph
JanusGraph – это распределенная, масштабируемая система графовых БД с открытым кодом и широким набором возможностей по интеграции и аналитике больших данных. Ниже приведен перечень основных функций JanusGraph:
Поддержка ACID-транзакций с возможностью одновременного обслуживания тысяч пользователей
Несколько вариантов хранения графических данных, включая Cassandra и HBase
Встроенный сложный поиск, а также дополнительная (опциональная) поддержка Elasticsearch
Полная интеграция Apache Spark для расширенной аналитики данных
JanusGraph использует полный по Тьюрингу язык запросов для обхода графов
Neo4j
Neo4j (Network Exploration and Optimization 4 Java, что переводится как «исследование сети и оптимизация для Java») – это графовая база данных, написанная на Java с нативным хранением и обработкой графов. Основные возможности:
Масштабируемость БД за счет разделения данных на части – сегменты
Высокая доступность благодаря непрерывному резервному копированию и последовательным обновлениям
Высокий уровень безопасности: несколько экземпляров баз данных можно разделить, оставив их на одном выделенном сервере
Neo4j использует Cypher – язык запросов для графовых БД, который очень удобен для программирования
DGraph
DGraph (Distributed graph, что переводится как «распределенный граф») – это распределенная система графовых БД с открытым исходным кодом и хорошей масштабируемостью. Вот несколько интересных возможностей DGraph:
Горизонтальная масштабируемость для работы в реальной среде с ACID-транзакциями
DGraph – это свободно распространяемая система с поддержкой множества открытых стандартов
Язык запросов – GraphQL, который был разработан для API
DataStax Enterprise Graph
DataStax Enterprise Graph – это распределенная графовая БД на базе Cassandra. Она оптимизирована под предприятия. Несколько функций:
DataStax обеспечивает постоянную доступность для корпоративных нужд
База данных легко интегрируется с автономной платформой Apache Spark
Полная интеграция аналитики и поиска в реальном времени
Масштабируемость за счет наличия нескольких центров обработки данных
Поддержка Gremlin и CQL для запросов
Плюсы и минусы графовых баз данных
В каждом типе баз данных есть свои плюсы и минусы. Именно поэтому так важно понимать отличия между моделями и доступные возможности для решения конкретных проблем. Графовые БД – это развивающаяся технология с целями, отличными от других типов БД.
Плюсы
Вот несколько плюсов графовых баз данных:
Гибкая и адаптивная структура
Четкое представление взаимосвязей между сущностями
Запросы выводят результаты в реальном времени. Скорость зависит от количества связей
Минусы
Ниже перечислены основные минусы системы:
Отсутствует стандартизированный язык запросов. Язык зависит от используемой платформы
Графы не подходят для систем на основе транзакций
Небольшая база пользователей; при возникновении проблема сложно получить поддержку
Заключение
Графовые базы данных – это отличный подход для анализа сложных отношений между объектами данных. Быстрота запросов и результаты в режиме реального времени хорошо вписываются в требования современных и стремительно растущих исследований данных. Графы – это развивающаяся технология, которую ждет еще много улучшений.