Итак, откуда у жесткого диска команда TRIM

К сожалению, правильный ответ на вопрос дали немногие читатели. И это действительно диск с SMR, а наличие поддержки TRIM у жесткого диска – 100% признак черепицы.

Коротко вспомним, что SMR диск, как и SSD, имеет большой штраф на запись, потому что мы не можем изменить один кластер, не перезаписав всю ленту. Поэтому запись всегда идет в свободные ленты или медиакеш с обычной технологией записи.

В моменты простоя диск начинает заниматься реорганизацией, т.е. перемещать записанные данные в занятые ленты, чтобы увеличить количество свободных, здесь же и начинает работать TRIM, также как и в SSD сообщая об удаленных на уровне файловой системы данных.

Это позволяет диску более эффективно реорганизовывать данные и поддерживать максимальный запас свободных лент.

Более подробно об этом в нашей статье: Что такое черепичная магнитная запись SMR и стоит ли ее избегать?

​​Почему именно systemd?

Практически после каждой нашей заметки о возможностях systemd в комментариях появляются читатели, которые пишут, что мол, а не проще ли это сделать … и далее идет перечисление простых утилит или скриптов.

С одной стороны, они могут показаться в чем-то правы. Зачем нужны все эти юниты, когда можно просто дернуть утилиту, получить результат и обернуть все это в скрипт.

Но это очень узкий и односторонний взгляд. Современные системы очень сложны и требуют стандартизации и унификации средств администрирования.

Вы можете мастерски владеть скриптами и автоматизировать все с их помощью, но ваши коллеги не сильно обрадуются этому факту, если им придется принять у вас обслуживание этой системы. Да и самому элементарно можно забыть, где лежит и для чего нужен тот или иной скрипт, особенно если подробного документирования не производилось.

Поэтому первый плюс systemd – это унификация и стандартизация. Теперь у нас есть юниты: юниты служб, юниты таймеров, юниты путей, юниты монтирования и т.д. и т.п.

Все юниты стандартизованы и научившись работать с одним типом вы без труда освоите другой. Кроме этого, юниты просты, очень просты и не идут ни в какое сравнение со скриптами.

Списки юнитов и их состояние также можно получить централизованно, одной простой командой. А чтобы проверить все возможные задания того же cron вам придется пробежать несколько каталогов, а также проверить crontab.

Второй плюс – это углубленная интеграция в систему, systemd предоставляет множество удобных инструментов, начиная от управления автозагрузкой и заканчивая средствами логирования.

Чтобы посмотреть результат работы скрипта – вам придется самому позаботиться о ведении лога. В systemd все это можно посмотреть «не отходя от кассы», стандартными инструментами. При этом никаких особых усилий к этому прикладывать не придется.

Из этого вытекает еще одно большое преимущество юнитов – их гораздо проще отлаживать. Во-первых, у вас уже есть лог, который ведется автоматически. Во-вторых, юниты предсказуемы и работают одинаково, вне зависимости от того, запущены они вручную или другим юнитом.
В тоже время отлично работающий при интерактивном запуске скрипт может оказаться неработоспособным при вызове через cron или из другого скрипта просто потому, что оказался запущен в другом контексте, с другими переменными окружения.

До сих пор нами были перечислены простые задачи, на которых преимущества systemd, конечно, видны, но еще не раскрыли всех своих возможностей.

Начнем с зависимостей. Как мы уже говорили – современные системы сложны. Многие их компоненты и службы зависят от других служб или предоставляемых ими ресурсов. Например, нам нужно выполнить какое-то задание, но только после того, как поднимется сеть и будут доступны некоторые сетевые ресурсы.

Для традиционного решения этой задачи придется немало поломать голову, выполнить кучу проверок или, как делается чаще всего, пойти по пути костылей и синей изоленты. Скажем, просто поставить задержку, в надежде что за это время сервис, от которого зависит работа успеет подняться. Ну а нет, так нет…

Systemd предоставляет простой и удобный способ работы с зависимостями. При этом вы можете указывать как отдельные службы, так и цели (таргеты), которые составляют группы служб, объединенные по некоторому признаку. Нужна сеть? Просто указываем в зависимостях network.target.

Еще одна важная задача – обработка отказа. Если служба упала – вы можете ее автоматически перезапустить. Но это можно сделать и без systemd, а вот systemd позволяет сделать это грамотно, указав частоту и количество попыток.

Если проблема приняла системный характер или находится на другой стороне, то systemd попробует несколько раз перезапустить службу и прекратит это делать, не получив результата. И это гораздо лучше, чем тупо долбить скриптом, вызывая повышенную нагрузку на систему и сеть.

Размер заметки не дает углубиться в подробности, но даже перечисленное дает исчерпывающий ответ на вопрос: почему именно systemd?

​​😎 systemd - управляем загрузкой служб

Прежде всего выясним статус службы, для этого выполним

systemctl status myservice

В выводе нас интересует следующая строка:

Loaded: loaded (/path_to/myservice.service; enabled; vendor preset: enabled)

Где loaded - обозначает что юнит проанализирован systemd и загружен в текущую конфигурацию, enabled - автозагрузка сервиса включена, vendor preset: enabled - статус автозагрузки по умолчанию, enabled обозначает, что служба будет автоматически добавлена в автозагрузку при установке пакета.

Для того, чтобы включить автозагрузку службы используйте:

systemctl enable myservice

При этом, чтобы два раза не вставать, можно сразу и запустить службу:

systemctl enable --now myservice

Для выключения автозагрузки выполните:

systemctl disable myservice

Посмотреть полный список служб в системе можно командой:

systemctl list-units --type=service

Вывод представляет собой несколько колонок:

🔹 UNIT - юнит службы

🔹 LOAD - статус юнита, loaded - загружен в конфигурацию systemd

🔹 ACTIVE - текущий статутс, показывает запущена ли служба

🔹SUB - более низкоуровневое состояние, зависит от типа юнита, так running показывает что служба запущена и работает, а exited - что она выполнила свою задачу и прекратила работу.

☝️ Также существует простой и удобный способ узнать текущий статус службы.

Чтобы проверить запущена ли она, выполните:

systemctl is-active myservice

Включена ли в автозагрузку:

systemctl is-enabled myservice

Завершился ли ее запуск ошибкой:

systemctl is-failed myservice

👍 Код завершения команды при положительном ответе - 0, что позволяет удобно выяснять состояние служб в скриптах.

Ананас в аренду?

В 18 веке ананасы считались признаком богатства и власти по всей Европе. Фрукт был настолько почитаем, что люди даже арендовали ананасы на ночь, чтобы показать их своим друзьям.

А сколько ещё удивительных вещей вы не знаете?
Наш канал Кот учёный – ваш проводник в мир интересных фактов!
Подписывайся’!👇
https://yangx.top/kot_u4enyy

erid: 2W5zFGM7MWG

​​Стандартные systemd target в Linux

Говоря о юнитах systemd, нельзя не отметить такой тип юнита как таргет (цель, taget). Таргет – это особый тип юнита, который позволяет объединить несколько юнитов в группу и управлять ими как единым целым.

Вы можете создать собственный таргет из взаимозависимых служб и, скажем, одновременно перезапускать все относящиеся к веб-серверу службы: веб-север, СУБД, PHP и т.д.

Но об этом мы поговорим как-нибудь позже, а сегодня наше внимание займут стандартные таргеты.

Посмотреть список стандартных целей можно командой:

systemctl -–type=target

После чего мы увидим список всех активных таргетов, чтобы увидеть полный список используйте команду:

systemctl -–type=target -–all

Что в этом полезного и для чего мы можем их использовать? Прежде всего для указания зависимостей. Допустим нам нужно, чтобы наша служба запускалась после того, как будет инициирована сеть, нет ничего проще:

After=network.target

Если вы используете сетевые файловые системы, такие как NFS или CIFS/SMB и ваша служба должна запуститься после того, как они будут смонтированы:

After=remote-fs.target

И не нужно ничего придумывать, systemd уже подумала за вас.

У некоторых целей может быть сразу несколько вариантов, например, существуют сразу три сетевых таргета:

▫️ network-pre.target
▫️ network.target
▫️ network-online.target

Цель network-pre.target представляет собой точку состояния системы перед запуском сетевых служб и может быть использована для запуска тех служб, которые обязательно должны быть активны на момент запуска сети, например, брандмауэр.

Данная цель должна использоваться как Before=network-pre.target или Wants=network-pre.target.

Собственно network.target обозначает состояние запуска всех сетевых служб системы и для прочих юнитов, которым нужна сеть мы должны использовать After=network.target, т.е. состояние после того, как все сетевые службы были запущены.

И, наконец, network-online.target – это точка состояния системы, когда все сетевые службы успешно и гарантированно запущены. Используется только с Wants= и After=, используется в основном для устаревших служб или сценариев, которые некорректно работают с After=network.target.

Отдельного разговора заслуживают Boot targets – цели загрузки, эти таргеты являются аналогами уровней запуска init. Существуют следующие загрузочные таргеты:

▫️ poweroff.target (runlevel 0) – выключение системы
▫️ rescue.target (runlevel 1) – режим восстановления системы
▫️ multi-user.target (runlevel3) – многопользовательский режим (консольный режим без графики)
▫️ graphical.target (runlevel 5) – режим графического окружения
▫️ reboot.target (runlevel 6) – перезагрузка системы

Также существует загрузочный таргет по умолчанию - default.target, который является символьной ссылкой на один из загрузочных таргетов и определяет в какой именно режим будет загружена система по умолчанию.

Узнать текущее состояние по умолчанию можно командой:

systemctl get-default

А установить новую цель загрузки можно командой:

 systemctl set-default graphical.target

При этом graphical.target имеет одну особенность, при отсутствии графики он запускается и работает аналогично multi-user.target и поэтому не следует удивляться, увидев его в системе без графической оболочки или в контейнере.

По-умолчанию graphical.target для систем без графического окружения используют Debian и Ubuntu.

Также мы можем переключаться между уровнями загрузки без перезагрузки системы при помощи команды isolate. Так если мы выполним в графической среде:

systemctl isolate multi-user.target

То все графические модули будут остановлены, и система перейдет в режим командной строки.

Ну и напоследок весьма злая шутка:

systemctl set-default reboot.target 👻👻👻

После чего можно принимать ставки как быстро коллега разберется в чем дело. Но такие шутки довольно вредны для здоровья. Минздрав предупреждает!

​​Как правильно редактировать юниты systemd

Сегодня systemd стал безальтернативной системой управления службами в дистрибутивах первого эшелона и предоставил администраторам простые и удобные возможности для решения этой задачи.

Действительно, сравните сложность написания init-файла и юнита. 🤷🏻‍♀️

И, как всякая хорошо спроектированная и продуманная система systemd предполагает многоуровневую систему управления юнитами.

Начнем с мест их расположения, которые перечислим в порядке повышения приоритета:

▫️ /usr/lib/systemd/system – юниты установленные вместе с пакетами
▫️ /run/systemd/system – юниты, которые создаются автоматически при загрузке системы и существующие только в рамках текущего сеанса
▫️ /etc/systemd/system – юниты, созданные системным администратором

Директория /etc/systemd/system имеет наивысший приоритет и если нам нужно изменить существующий юнит службы, то мы можем скопировать его сюда из /usr/lib/systemd/system и внести свои изменения.

Вроде бы просто, да не совсем. При обновлении пакета юнит в /usr/lib/systemd/system тоже будет обновляться, при этом, в отличии от изменения конфигурационных файлов, никакого предупреждения мы не получим.

Юнит пакета будет жить сам по себе, и наш, скопированный юнит тоже сам по себе. Но применяться, в силу приоритета, будет именно наш юнит.

К чему это может привести? Да к чему угодно и отловить причину внезапно возникшего непонятного поведения службы может быть достаточно проблематично.

Особенно критично это может быть при обновлении системы на новую версию, где исходный юнит службы может подвергнуться серьезным изменениям.

Как быть? К счастью, в systemd, как в хорошо спроектированной системе, есть возможность точечно вносить изменения в конфигурацию юнита при помощи технологии drop-in.

Скажем, нам нужно внести изменения в работу юнита myservice.service, для этого мы должны создать каталог /etc/systemd/system/ myservice.service.d и поместить в него один или несколько фалов с расширением conf.

Проще всего это сделать с помощью команды:

systemctl edit myservice

Напоминаем, что если вы не указали тип юнита, то по умолчанию он принимается за service, а если вам нужно внести изменения в таймер, то придется указать имя юнита полностью:

systemctl edit myservice.timer

Затем указываем только те опции, которые хотим переопределить или добавить, например:

[Unit]
Requires=новая зависимость
After=новая зависимость

Для опций, предполагающих множественные значения следует предварительно выполнить их сброс, иначе переопределяемое значение будет добавлено к уже существующему в файле юнита. К таким опциям относятся ExecStart или OnCalendar в таймерах.

Если вы добавите:

[Service]
ExecStart=новая команда

То эта строка будет добавлена к существующим строкам ExecStart в юните, если вы хотите переопределить это значение, то его сначала необходимо сбросить:

[Service]
ExecStart=
ExecStart=новая команда

Если у вас несколько Drop-in файлов, то изменения в них будут применяться по очереди, для расстановки приоритетов можете использовать цифровые префиксы файлов.

Еще одним достоинством команды systemctl edit является то, что по окончании редактирования конфигурация systemd будет перечитана, а служба перезапущена.

Откатить изменения можно командой

systemctl revert myservice

Если вы редактируете drop-in файлы вручную, то после каждого изменения перечитайте конфигурацию:

systemctl daemon-reload

И перезапустите службу

systemctl restart myservice

Как видим, systemd дает в руки администратора серьезные инструменты позволяющие точечно редактировать конфигурацию юнитов.

Мы рекомендуем использовать данный подход даже для внесения изменения в собственные юниты, так откатить изменения в drop-in файле проще, чем восстановить исходное состояние конфигурации службы.

Субботнее ночное

Со вчерашнего дня по дореволюционным проездным на пригородные поезда то пускают, то не пускают, то пускают, но не на все направления.

Что такое пригородные поезда рекомендуем почитать тут: https://yangx.top/interface31/3387

Похоже, халява накрылась. Теперь в область только на маршрутках, с импортными буквами на боку: X-RAY, VLESS, REALITY

Что они значат? Да пес его знает, наверное модель маршрутки.

Но вот пришлось искать и найти способ втиснуться туда с чадами, домочадцами и домашними животными прямо с железнодорожной платформы.

Да и маршрутки нечего так, быстрые, удобные.

​​Кеширующий прокси или зеркало репозитория?

Уже не первый раз сталкиваемся с тем, что начинающие администраторы путают эти два понятия. Поэтому попробуем внести ясность.

По мере роста количества машин под управлением Linux возникает проблема доступа к репозиториям. Например, при обновлении весь парк машин будет многократно выкачивать один и тот же объем трафика.

Дополнительными негативными факторами могут быть скорость канала или скорость доступа к репозиториям. Все это заставляет задуматься о том, как решить проблему.

Первое что приходит на ум – это локальное зеркало репозитория. Создать его несложно, для этого есть штатная утилита apt-mirror. С ее помощью можно поддерживать на собственных ресурсах полную копию репозиториев системы.

Но тут возникают иные сложности, так, например, размер репозиториев текущей версии Debian для архитектуры amd64 составляет 778 ГБ, сюда как минимум следует добавить all и еще 258 ГБ. Получаем примерно 1 ТБ требуемого дискового пространства.

Если у нас в эксплуатации несколько систем, то зеркала репозиториев нужно будет организовать для каждой из них. При переходе на новую версию – добавить новые репозитории.

В итоге получаем весьма значительное расходование места, причем достаточно бесполезное, поскольку по факту вы будете использовать лишь малую его часть.

Уменьшить размер локальных репозиториев в целом можно, например, скачав только самые нужные или оставив только последние версии пакетов, но все это не устраняет общей проблемы – значительный перерасход места.

Альтернатива локальному репозиторию – кеширующий прокси-сервер. Он работает по схожему, но несколько иному принципу.

Как и любой прокси-сервер он становится посредником между системой и репозиторием и один раз скачав любой пакет помещает его в локальный кеш. При последующих запросах пакет будет уже отдаваться из кеша, без повторного скачивания.

Локальная структура также организуется по принципу репозиториев, с учетом версии системы, архитектуры, источника пакетов и т.д.

Поэтому один кеширующий прокси может без проблем обслуживать любое количество систем и их версий. Никаких настроек при этом делать не надо. Новая система первый раз скачает необходимые файлы из интернета, а остальные получат их уже из локального хранилища.

Потребовался новый пакет или обновление? Аналогично, один раз качаем, остальное получаем локально.

При этом размер кеша будет равен размеру реально используемых пакетов и их версий. И разница с локальным репозиторием получается где-то на порядок.

Поэтому для большинства сценариев оптимальным будет использование именно кеширующего прокси.

Локальные репозитории в свою очередь следует использовать для закрытого контура или крупных систем с узким внешним каналом.

Настроить кеширующий прокси Apt-Cacher NG можно по нашей статье: Установка и настройка Apt-Cacher NG - кеширующего прокси-сервера обновлений для Debian и Ubuntu

​​Большой SLC-кеш, хорошо ли это?

Сегодня основным типом твердотельного накопителя является накопитель с типом ячеек TLC, три бита на одну ячейку. Другой памяти вы в современных дисках не найдете, за исключением QLC – еще более медленной с четырьмя битами на одну ячейку.

Те редкие модели с памятью MLC которые сегодня можно встретить в продаже относятся к устаревшим моделям с интерфейсом SATA и их скоростные характеристики оставляют желать лучшего.

Сама TLC память достаточно медленная, и чтобы улучшить скоростные характеристики накопителя был придуман SLC-кеш.

Сразу скажем, что никакой отдельной памяти для этого кеша нет, просто в SLC-режим переводится часть ячеек накопителя. А так как SLC – это один бит на ячейку, то емкость ячейки падает в три раза для TLC и в четыре для QLC.

Таким образом максимальный объем SLC кеша для TLC не может превышать 33,3% емкости накопителя, а для QLC – 25%.

Режим кеширования производителем не разглашается и зависит от программных настроек прошивки контроллера, но бытует мнение, что чем больше размер кеша, тем лучше. Но это далеко не так. Почему?

Один из распространенных алгоритмов кеширования предусматривает выделение под кеш большого объема, примерно в 30% от общего объема накопителя.

Что это значит? Это значит, что мы перевели в SLC-режим практически всю память, потому что 30% кеша – это 90% объема.

Да, такой кеш будет поддерживать высокую скорость записи, но по его исчерпанию диску просто становится некуда писать. Поэтому ему приходится одновременно уплотнять запись, переводя SLC-ячейки в TLC-режим и принимать новые данные. При этом скорость записи катастрофически падает, местами до 100 МБ/с и ниже.

Другая стратегия предлагает выделение небольшого объема под кеш 5-10% емкости диска. При этом основная часть ячеек диска остается в режиме TLC и по исчерпании кеша вполне способны обеспечить скорость записи в районе весьма комфортных 400 – 500 МБ/с.

Что из этого лучше? Однозначного мнения тут нет и быть не может. Все зависит от сценариев работы. В первом случае вы сможете принять на полной скорости примерно треть свободного объема диска, но потом получите скорость улитки, попавшей в студень.

Во-втором на полной скорости получится записать лишь небольшой объем данных, но за пределами кеша также будет сохраняться вполне комфортная скорость.

Поэтому если ваши сценарии предусматривают запись значительных объемов данных, то дополнительно будет неплохо почитать обзоры и выяснить алгоритмы кеширования выбранного диска.

При этом помните, что это сугубо программная настройка. И на рынке присутствует множество моделей абсолютно одинаковых аппаратно, но имеющие разные алгоритмы кеширования и, соответственно, разные скоростные характеристики.

Аренда выделенного сервера от АТОМДАТА под любые задачи

Бесплатное тестирование оборудования!

Аренда физического сервера в любой точке РФ:
- SLA 99,98 с финансовой компенсацией;
- Оперативный подбор конфигурации под задачу, бюджет или по другими параметрам;
- Техническая поддержка 24/7. 3 линии поддержки
- Быстрое предоставление оборудования с собственного склада или подбор и закупка под проект;
- Размещение оборудования в собственных ЦОДах "Росатома", а также партнерских ЦОДах в РФ или на площадке заказчика;
- Помощь с настройкой ПО и запуском оборудования;

Конфигурации в аренду:
- Импортозамещенные серверы/Серверы из реестра Минпромторга (Kraftway);
- Бюджетные (HP DL 360);
- Высокопроизводительные (HP);
- Enterprise (ASUS/INSPUR);
- СХД (HPE/Huawei).

Подробности и бесплатная консультация

#реклама
О рекламодателе

​​Журналирование при помощи systemd

Про управление службами при помощи systemd мы уже рассказывали: https://yangx.top/interface31/956

Но на этом его возможности не исчерпываются, systemd берет на себя автоматическое журналирование и ротацию логов. Причем в лог будет писаться любой вывод процесса, даже если вы ничего не настраивали.

Это удобно, особенно для простых скриптов, запускаемых по таймерам, в случае использования Cron вам бы пришлось самостоятельно озадачиться логированием.

Самая известная команда для просмотра логов, это:

journalctl -xe

Которая предлагается системой при неудачном запуске сервиса. Ключ -х предписывает выводить ссылки или пояснения для стандартных ошибок, а -e «перематывает» журнал к последней записи.

Для просмотра текущих сообщений лога в реальном времени введите:

journalctl -f

Для вывода последних событий укажите:

journalctl -n 50

Что выведет 50 последних записей, по умолчанию выводится 10.

Чтобы посмотреть сообщения ядра используйте

journalctl -k

Для того, чтобы посмотреть логи определенной службы укажите ее имя после ключа -u:

 journalctl -u myservice

Чтобы ограничить журнал текущей загрузкой используйте:

journalctl -b 0

Предыдущие сеансы будут иметь отрицательные номера в сторону уменьшения, так предыдущая загрузка будет:

journalctl -b -1

А список всех доступных загрузок можно получить:

journalctl --list-boots

Для получения событий с указанием времени используйте:

journalctl --since “2023-09-20” --until “2023-09-22 12:30:00”

Где --since – обзначает нижний предел фильтра, --until – верхний. Дата вводится в формате ГГГГ-ММ-ДД ЧЧ:ММ:CC, время, при необходимости, можно пропустить.

Также можно отфильтровать сообщения по приоритету, всего используются следующие уровни приоритета:

▫️0 emergency (неработоспособность системы)
▫️1 alerts (предупреждения, требующие немедленного вмешательства)
▫️2 critical (критическое состояние)
▫️3 errors (ошибки)
▫️4 warning (предупреждения)
▫️5 notice (уведомления)
▫️6 info (информационные сообщения)
▫️7 debug (отладочные сообщения)

Приоритет уменьшается с увеличением номера. Так если мы хотим отфильтровать только ошибки и более значимые сообщения, то достаточно указать:

journalctl -p 3

Ключи можно сочетать, например, выведем все сообщения ядра от ошибки и серьезнее за текущий сеанс работы:

journalctl -k -b 0 -p 3

По умолчанию journalctl разбивает вывод на страницы, если нужно изменить такое поведение, скажем для перенаправления вывода в файл, то укажите:

journalctl --no-pager

Также используя ключ -o можно вывести сообщения в формате JSON или syslog, для этого нужно будет указать:

▫️json: стандартный формат JSON с одной записью на строку.
▫️json-pretty: код JSON в формате, более удобном для чтения человеком
▫️short: вывод в формате syslog по умолчанию
▫️short-iso: формат по умолчанию, дополненный для отображения временных меток часов ISO 8601.

journalctl -b 0 -p 3 -u myservice -o json

Как видим, journalctl весьма мощная и удобная система, позволяющая не только собирать, но и удобно просматривать логи без применения дополнительных инструментов.

​​Loginctl – управляем пользователями и сессиями

Сегодня мы расскажем еще об одной простой и удобной утилите из состава systemd – loginctl, которая предназначена для управления пользователями и сессиями.

Вообще-то утилита оперирует тремя типами объектов:

▫️session – сессия, каждая авторизация пользователя в системе, исключая sudo и su.

▫️user – пользователь системы, который может иметь одну или несколько сессий одновременно.

▫️seat – рабочее место, имеет актуальность только для терминальных сред.

Начнем с просмотра, чтобы увидеть все активные сессии введите:

loginctl list-sessions

или просто

loginctl

Для вывода всех выполнивших вход пользователей:

loginctl list-users

Для вывода текущего состояния пользователя или сессии выполните:

loginctl user-status <username>

или

loginctl session-status <ID>

Где вам потребуется указать имя пользователя или идентификатор сессии.

Вместе с информацией о сессии или пользователе вы также увидите дерево запущенных от его имени процессов.

Чтобы увидеть подробности конкретной сессии или пользователя следует использовать команды:

loginctl show-session <ID>
loginctl show-user <username>

Для завершения сессии можно использовать:

loginctl kill-session <ID>

При этом всем процессам сессии будет послан сигнал SIGTERM, если мы хотим это изменить, то можем указать сигнал явно:

loginctl kill-session <ID> --signal SIGKILL

В качестве альтернативы можно использовать:

loginctl terminate-session <ID>

В целом обе команды дают аналогичный результат, но terminate не позволяет явно указывать сигнал и для завершения процессов использует инструменты systemd, такие как StopUnit().

Если мы хотим завершить все сессии пользователя, то можно использовать:

loginctl kill-user <username>

или

loginctl terminate-user <username>

В графическом интерфейсе мы можем блокировать или разблокировать экран командами:

loginctl lock-session | unlock-session <id>

Также можем переключаться на нужную сессию:

loginctl activate <id>

Еще один интересный момент, это управление службами пользователя. Обычно они запускаются при интерактивном входе пользователя в систему и останавливаются при его выходе.

Однако бывает необходимость, чтобы они стартовали без входа в систему, в таком случае используйте команду:

loginctl enable-linger <username>

Чтобы отключить такое поведение:

loginctl disable-linger <username>

Как видим, systemd – это не только службы, но и обширный набор простых инструментов для полноценного управления вашей Linux-системы.

В коллекции брелков очередное пополнение

Процессор Ryzen 5 PRO 4650G – модель хорошая, привлекательная по соотношению цена/возможности. Шесть ядер с базовой частотой 3,7 ГГц и с автоматическим разгоном до 4,2 ГГц при базовом тепловом пакете 65 Вт – это как раз то, что доктор прописал для многих простых задач.

И не только на рабочих станциях, но и в серверах начального уровня. Под ту же 1С человек на 5 – 10, да не просто 1С, а еще и с виртуалками. В общем много для чего, где надо недорого, но с достаточной производительностью как общей, так и на один поток.

Но только вот практика эксплуатации показала, что модель вышла не очень удачная в плане надежности. Скажем проще – они дохнут. Внезапно, без всякой причины и воздействия внешних факторов. Вы можете просто перезагрузить ПК и получить кирпич, точнее не совсем кирпич, материнская плата порадует вас крутящимися вентиляторами, ЛГБТ* RGB-подсветкой и радостным миганием светодиода CPU.

У нас этих камушков насобиралась уже целая коробочка и вот еще один подъехал. При том, что ни у серий 2хххG, 3xxxG и более новой 5xxxG таких проблем нет.

В настоящий момент наиболее привлекательной заменой является Ryzen 7 5700G, который все тоже самое, только лучше и примерно за те же самые деньги.

* Признаны в России экстремистскими.

​​Критерии выбора оборудования для сервера 1С:Предприятие. Процессор. Часть 1

Тема выбора оборудования для сервера 1С актуальная и с завидной регулярностью поднимается в комментариях. Поэтому сегодня уделим внимание этому вопросу.

Критически важным для 1С является частота центрального процессора, это связано с рядом особенностей, которые мы опишем ниже, точнее даже не с частотой как таковой, а с однопоточной производительностью, которая с частотой обычно связана напрямую.

Ниже 3 ГГц можете даже не смотреть, а лучше выбрать процессоры с частотой около 4 ГГц. Что касается буста, то смотрите не на абсолютные цифры частоты, а на то, как именно процессор ее поднимает, будет лучше если он одновременно может поднимать частоту сразу всех ядер.

А теперь перейдем к тому, почему это так. В админской среде гуляет мнение, что это от того, что 1С написана левой задней лапой и не умеет в многопоточность. Однако это не так. Умеет и там, где может – распараллеливается. Но может это сделать не везде.

Начнем с того, что 1С – это учетная система, предназначенная для ведения бухгалтерского и управленческого учета, расчета заработной платы и многих других специфичных вещей.

И именно предметная часть накладывает серьезные ограничения, бухгалтерия – не математика. Мы не можем взять и вычислить параллельно части выражения и потом произвести окончательные вычисления, в учете многие операции можно делать строго последовательно, в один поток.

Чтобы было проще понять, о чем мы говорим приведем очень сильно упрощенный пример: вы не можете продать товар пока не оприходуете его на склад, а оприходовать не сможете раньше, чем внесете оплату поставщику.

Нет, конечно, технически это сделать можно и если считать только товар на складе и деньги в кассе, то вроде бы все и нормально. Но с точки зрения бухучета это будут абсолютно разные хозяйственные операции и абсолютно разный хозяйственный результат.

Поэтому всегда исходим из того, что у нас будут преимущественно однопоточные нагрузки и наш сервер должен уметь быстро и эффективно их обрабатывать.

Индикатором комфортной работы отдельного пользователя служит широко известный тест Гилева. Который проверяет способность оборудования переварить именно однопоточную нагрузку.
С увеличением количества пользователей растет количество однопоточных задач и нам нужно уметь быстро их обработать. Поэтому следующим вопросом становятся ядра и потоки. Их должно быть достаточно.

Точно сказать сколько надо ядер и потоков на N-пользователей обычно не представляется возможным, так как даже на одной и той же конфигурации, с одним и тем же количеством пользователей и даже с примерно одинаковым размером базы характер нагрузки может быть принципиально разный.

Так у производства и торговли будут совершенно разные сценарии. Да и торговля бывает разной, у кого-то есть партионный учет, у кого-то ВЭД и курсовые разницы и т.д. и т.п.

Где-то нагрузка будет равномерной, где-то пиковой. Все зависит от параметров учета конкретного предприятия. И советовать какое-то железо только исходя из конфигурации и количества пользователей – дело неблагодарное, кому-то ее будет с избытком, а кому-то сразу станет тесно.

Учитывая, что редко кто делает крупные внедрения 1С с нуля, всегда имеется возможность оценить характер нагрузки на уже имеющемся оборудовании и прикинуть необходимый вектор развития.

А также выяснить характер нагрузки и установить кто именно ее производит. Например, мы сталкивались с тем, что сильные пиковые нагрузки производила база ЗуП (Зарплата и управление персоналом), в которой работало три человека. В таких сценариях имеет смысл выносить подобные нагрузки на отдельные экземпляры Сервер-МИНИ.

Объем заметки не позволяет охватить все аспекты, поэтому на сегодня закончим. А в следующей заметке поговорим о менее очевидных вещах: рабочих процессах и веб-клиентах.

Интересно попробовать себя в роли 1С-разработчика? Тогда приглашаем на бесплатный интерактивный мастер-класс «Создаём конфигурацию в 1С 8.3 с нуля» от экспертов компании Programming Store. Участники смогут в режиме реального времени влиять на ход вебинара и итоговую конфигурацию.

📍24 апреля в 16:00 (МСК)
📍ссылка на регистрацию

В программе:
— создадите с нуля свою первую конфигурацию в 1С;
— познакомитесь с основными объектами 1С;
— поймёте практическую пользу 1С для бизнеса.

Регистрируйтесь и получайте практические знания😉

erid: 2W5zFJYeJhv

​​Критерии выбора оборудования для сервера 1С:Предприятие. Процессор. Часть 2

Во вчерашней заметке мы разобрали общие вопросы производительности сервера 1С в разрезе процессора, сегодня продолжим углубляться в специфику.

Рабочие процессы (rphost) – основная рабочая лошадка, которая выполняет серверный код и обслуживает пользовательские соединения. В целом рабочий процесс умеет эффективно использовать ядра процессора, но есть некоторые тонкости.

Официальная документация гласит:

…при работе на многопроцессорных системах, в зависимости от характера нагрузки, может наблюдаться неравномерная загрузка процессоров/ядер. В некоторых случаях может оказаться загружена только какая-то часть доступных ядер CPU, при этом другая часть будет простаивать. В таких случаях рекомендуется использовать лимит числа соединений на рабочий процесс…

Фактические рекомендации сводятся к тому, чтобы равномерно распределить рассчитанный максимум соединений на доступные ядра процессора, а если нагрузка будет продолжать оставаться неравномерной, то уменьшать этот лимит.

Проще говоря – количество рабочих процессов рекомендовано выставлять по количеству ядер.

Но тут беда пришла откуда не ждали, после разделения платформы на ПРОФ и КОРП. Теперь у пользователей ПРОФ нет возможности настраивать рабочие процессы, единственное доступное значение 8 ИБ на процесс и 256 соединений. Также платформа ПРОФ не может использовать более 12 процессорных ядер.

Это говорит о том, что в большинстве случаев вы будете работать в рамках единого рабочего процесса и иметь все прелести неравномерной загрузки, в этом случае также крайне важно иметь CPU с максимально высокой частотой процессора.

Отсюда проистекает также и схема масштабирования. Если ваши масштабы не предполагают переход на КОРП, а на одном сервере всем становится тесно, то лучший вариант – это увеличение количества серверов 1С.

Где-то ряд нагрузки можно вынести на Сервер-МИНИ, а где-то имеет смысл приобрести еще одну лицензию. При этом аппаратно можно продолжать использовать уже имеющееся оборудование.

Скажем тот же AMD Ryzen 9 5900X имеет 12 ядер / 24 потока, что позволит полноценно развернуть на нем две виртуальных машины или контейнера с серверами 1С по 12 ядер в каждом.

Следующий тонкий момент – веб-сервера, которые сейчас очень популярны как средство доступа к 1С.

Здесь мы начнем с вопроса: где исполняется код 1С? А исполняется он в двух местах: на клиенте и на сервере. На клиенте обрабатываются данные форм приложения и данные введенные в них пользователем.

Данные ИБ можно получить только на сервере и обычно там же происходит их обработка. Количество кода, исполняемого клиентом и сервером, различается от характера нагрузки.

При установке на компьютер пользователя платформы в режиме тонкого клиента, работающего через веб-сервер весь код клиентского приложения исполняется прямо на нем. А веб-сервер служит простым ретранслятором запросов к серверу, практически не оказывая нагрузки.

Если же доступ ведется через веб-клиент (браузер), то код, исполняемый на клиентской стороне, выполняет модуль расширения веб-сервера и вся нагрузка ложится на веб-сервер. Этот момент также нужно учитывать при планировании нагрузки.

Следующий момент – это сеансы и соединения. Сеанс определяет активного пользователя информационной базы и поток управления этого пользователя. Среди доступных видов сеансов есть тонкий клиент и веб-клиент.

Соединение является средством доступа сеансов серверу 1С:Предприятия» и не отождествляется с активным пользователем. Среди видов соединений есть также тонкий клиент и модуль расширения веб-сервера.

О чем это говорит? О том что в режиме работы через веб-сервер количество сеансов не равно количеству соединений. И чаще всего множество входящих сеансов к веб-серверу обслуживаются единственным соединением к серверу 1С:Предприятия.

Поэтому здесь разумно будет распараллеливать нагрузку путем увеличения количества веб-серверов, а также обязательно разносить веб-сервера обслуживающие пользователей и используемые для веб-сервисов.

​​Критерии выбора оборудования для сервера 1С:Предприятие. Память

Вопрос выбора оперативной памяти, а точнее ее необходимого количества является с одной стороны простым, а с другой – весьма и весьма сложным и ниже мы поговорим почему.

Мы не будем касаться аппаратной части выбора, здесь все ясно – чем быстрее память, тем лучше, но такого критического значения как у процессора ее частота не имеет.

Основными критериями выбора будет являться ее необходимый объем.

На первый взгляд тут все просто, оцениваем выделение памяти на один работающий сеанс, умножаем на число сеансов. Посмотреть эти значения можно в оснастке Администрирование серверов 1С:Предприятие

Идем в сеансы и смотрим следующие показатели, естественно – в разгар работы: Память (5 мин) и Память (всего). Первый показатель покажет максимальное значение потребления памяти за пять минут, второй – за сеанс.

Исходя из них вычисляем среднее и пиковое потребление. Опять-таки, дать каких-то конкретных советов и цифр тут сложно, следует исходить из реальной обстановки.

А в реальной обстановке у нас могут иметь место утечки памяти, чаще всего по вине неоптимальных доработок или внешних отчетов, но могут «течь» и вполне типовые конфигурации.

Второе зло – зависшие сеансы. Стандартный срок жизни такого сеанса – 86400 секунд или 24 часа, что достаточно много. Возникать такие сеансы могут по многим причинам, чаще всего от мобильных пользователей, которые несколько раз переподключаются к серверу перемещаясь от одного провайдера к другому.

В результате реальное количество сеансов может оказаться существенно выше запланированного и привести к неприятным последствиям.

Дело в том, что у платформы уровня ПРОФ отобрали все инструменты управления памятью и заставили довольствоваться параметрами по умолчанию.

Первый из них: Временно допустимый объем памяти процессов, по умолчанию он равен 70% памяти сервера. Второй связанный с ним параметр: Интервал превышения допустимого объема памяти процессов, равный 300 секундам (5 минут).

Таким образом, если рабочие процессы на протяжении более 5 минут будут потреблять более 70% памяти сервера, то начнется их мягкий перезапуск. Для этого создается новый рабочий процесс и ему передаются текущие сеансы, после того как все сеансы будут переданы – процесс будет завершен.

При этом начнет сервер с самого «жирного» рабочего процесса. А теперь снова вспомним об ограничениях платформы ПРОФ и придем к пониманию, что самым «жирным» будет один единственный доступный нам рабочий процесс со всеми сеансами.

При этом далеко не факт, что нам хватит свободной памяти перенести все сеансы. Потому как 70% - это довольно высокий лимит, да и сама ОС тоже нуждается в памяти.

После чего на сцену выходит еще один параметр: Критический объем памяти процессов – по умолчанию 95% объема памяти сервера.

По его достижении рабочие процессы начинают завершаться аварийно, начиная с самого «жирного», а в нашем случае – единственного.

Но это мы рассмотрели сферический сервер в вакууме, в реальности администраторы очень любят совмещать все на одном узле. И сервер 1С, и сервер СУБД, и веб-сервер. Во многом это обусловлено многочисленными материалами типа «Сервер 1С с нуля за пять минут», где просто дается последовательность действий и не поясняется архитектура системы.

А как мы могли видеть все показатели завязаны именно на объем памяти сервера и не поддаются изменению.

В таком случае сервер просто никогда не доберется до перезапуска процессов, а просто тупо уйдет в аут исчерпав всю доступную оперативную память.

Выводы здесь довольно очевидны: обязательно выносим сервер 1С:Предприятие в отдельную виртуалку или контейнер и не совмещаем его с никакими другими ролями.

Рассчитываем потребности в памяти и накидываем сверху запас на зависшие сеансы и утечки памяти. А также принимаем меры по контролю сеансов и не забываем мониторить потребление памяти внутри системы с сервером 1С.