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

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

Аренда физического сервера в любой точке РФ:
- 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С.

Заглядываем в конфиги и превращаем хаос в систему

💬 Шёпотом: курс «Ansible: Infrastructure as Code» стартует 28 апреля.

Подойдёт всем, кто хочет научиться:

🔹 работать с подходом IaC и автоматизировать рутину;
🔹 выполнять всякие сложные задачи типа блоковой замены, управления потоком выполнения и пр.;
🔹 настраивать Ansible под необходимые задачи;
🔹 писать свои модули;
🔹 решать сисадминские задачи;
🔹 встраивать Ansible в пайплайн Gitlab и много чего ещё.

Успевайте оформить обучение, пока действует ранняя цена 🤝

Программа курса и все подробности — по ссылке ⬅️

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

Ой, да чего там выбирать, все равно все данные лежат в СУБД, вот для сервера СУБД диски и подберем, а серверу 1С какой-нибудь SSD купим.

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

Сейчас мы будем говорить только о сервере 1С и не будем касаться сервера СУБД, даже если они расположены на одной машине.

Итак, какие данные сервер 1С хранит на диске? В первую очередь это сеансовые данные, которые хранятся в директории с именем snccntx + уникальный идентификатор. В Windows она располагается в C:\Program Files\1cv8\srvinfo\reg_1541, в Linux в /home/usr1cv8/.1cv8/1C/1cv8/reg_1541.

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

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

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

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

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

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

В той же директории, рядом с папкой сеансовых данных можно найти папки с именами, состоящими из уникальных идентификаторов, по одной на каждую информационную базу. Там находятся профайлы с настройками и каталоги 1Cv8FTxt и 1Cv8Log.

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

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

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

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

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

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

​​Еще раз про Load Average и логические / виртуальные ядра

Сегодня в очередной раз столкнулся с неверным пониманием такого важного параметра, как Load Average.

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

На самом деле это не так, потому что Load Average – это не физический параметр и тем более не показатель нагрузки на CPU или его производительности.

Это относительное значение, показывающее доступность вычислительных ресурсов в системе.

Мы знаем, что процессор выделяет каждому нуждающемуся в вычислениях процессу некоторое время, называемое тиком, в течении которого процесс получает доступ к вычислительным ресурсам ЦПУ.
Если мы возьмем некоторое время, а при вычислении LA берется промежуток из 5000 тиков, то это самое количество тиков мы можем принять за 100% или единицу.

Таким образом значение 1 для LA означает, что все тики были отданы процессам, но очереди не возникло. А если LA = 0.25 – то это значит, что процессы использовали только четверть доступных тиков.

А если процессов больше, чем доступных тиков? Возникает очередь и LA начинает принимать значения выше единицы. При этом LA > 1 вовсе не означает недостатка именно процессорных ресурсов, процесс может не использовать свой тик по причине ожидания, например, дискового ввода вывода.

Таким образом тормозная дисковая подсистема также может сильно увеличить значение LA при фактическом простое процессора.

Корректно ли это? Да, корректно, так как процесс нуждается в вычислительных ресурсах, но не может их получить, по какой причине – это уже совсем отдельная история.

Что будет если мы добавим еще одно ядро, не важно физическое, логическое или виртуальное. У нас появятся еще 5000 тиков и полной нагрузке на систему будет соответствовать LA = 2.

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

Но теперь за одну и ту же единицу времени доступ к CPU получат уже не 5 000, а 10 000 процессов. А, как известно, лучше плохое ехать, чем хорошо стоять.

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

https://interface31.ru/tech_it/2016/06/linux-nachinayushhim-chto-takoe-load-average-i-kakuyu-informaciyu-on-neset.html

​​Адаптеры PowerLine – практические особенности эксплуатации

С приходом весны и тепла у моего товарища снова поднялся насущный вопрос – как провести нормальный интернет в гараж. Wi-Fi туда вроде как и добивал, но делал это как-то нестабильно, с нерегулярной скоростью и разрывами. Средняя скорость приема в гараже была около 20-25 Мбит/с.

Радикальное решение – протянуть витуху – не рассматривалось. Потому как делать это плохо, тупо бросив воздушку не хотелось, а хорошо – протянуть по подсобным помещениям выходило слишком хлопотным мероприятием.

Поэтому решили рассмотреть альтернативные решения и тут мы вспомнили о таком типе оборудования как PowerLine-адаптеры, позволяющие поднять локальную сеть поверх питающей сети 200 В.

Теперь немного теории. Стандарт HomePlug AV предусматривает использование двух проводов и использует рабочие частоты 1,8 – 30 МГц позволяя достигать скоростей до 100 Мбит/с. Стандарт HomePlug AV2 дополнительно использует третий провод (нейтраль) и частоты до 80 МГц, что позволяет реализовать скорости до 1 Гбит/с.

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

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

Для покупки выбрали на Озоне PowerLine PLC RP-901TR v.2 пара которых обошлась нам в 1500 руб. (сейчас можно найти дешевле), адаптеры б/у от МГТС, но отзывы о них вполне хорошие.

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

Сначала решили провести синтетические тесты, для этого включили оба адаптера в один пилот и взяв два ноутбука запустили iperf. В результате стабильная скорость между ними установилась на 800-850 Мбит/с, при длительной нагрузке (мы гоняли тест около 15 мин.) адаптеры начали ощутимо нагреваться.

Заменяем пилот обычным удлинителем на 2 провода из гаража, результат предсказуем 85-89 Мбит/с.

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

▫️ Адаптер - Пилот – Пилот – Пилот – Сеть – Пилот – Адаптер

▫️Результат: 10-15 Мбит/с

Выкидываем лишнюю цепочку из пилотов, оставляем:

▫️ Адаптер - Пилот – Сеть – Пилот – Адаптер

▫️Результат: 35-45 Мбит/с

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

▫️ Адаптер - Пилот – Сеть – Адаптер

▫️Результат: 70-75 Мбит/с.

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

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

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

Субботнее. О жизни.

Нашел фото 2013 года, 10 лет назад, классический джентельменский набор администратора.

Не хватает только сумочки с дисками и стопки болванок на шпинделе.

С тех пор многое изменилось. Компакт-диски вымерли как класс. У меня дома нет ни одного устройства с их поддержкой.

Популярные боксы Zalman-VE и их аналоги (точнее оригиналы) от IODD массово вытеснили флешки с Ventoy, который в последних версиях действительно хорош.

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

VPN и шифрование

VPN сейчас в тренде, понятно, время такое. Но вот то, что иногда делают с ним, вроде бы технически грамотные люди – решительно непонятно.

Любимое народное развлечение – это накрутить на туннель шифров, да побольше, да посильнее. Особенно любят баловаться этим на Mikrotik.

И мы сейчас не про VPN для удаленного доступа, а про тот который пойди туда не знаю куда. После чего сразу поступают вопросы – а чего это все так медленно?

Вот здесь и хочется спросить: а что и от кого вы шифруете? И зачем?

Безопасность на уровне приложений решается с помощью SSL (HTTPS) и это действительно надежно.

Хотим приватности от провайдера - добавляем DNS over HTTPS и этого достаточно.

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

Здесь хватит простого и быстрого шифра и нет никакого смысла во всяких AES-256 + SHA-512. Разве что дома холодно, и вы решили погреться от роутера.

​​USB 3.x и Wi-Fi 2,4 ГГц

Что у них общего? На первый взгляд ничего, где USB и где Wi-Fi, абсолютно разные технологии.

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

USB 3.x не исключение, частотный спектр сигнала которого пересекается с диапазоном Wi-Fi 2,4 ГГц и способен серьезно нарушить работу последнего, вплоть до полного пропадания связи.

Это, например, коротко описано в разделе техподдержки TP-LINK:

Согласно спецификации интерфейса USB 3.0, передача данных по данному стандарту затрагивает частотный диапазон в 2,4-2,5 ГГц.

В результате, большое количество шумов или интерференций сигнала возникает на частоте 2,4 ГГц, и как следствие, мешает корректной работе роутера.

Если устройство USB 3.0 расположено близко к антеннам роутера, роутер пользователя может испытывать серьезные воздействия на частоте 2,4 ГГц.

Кому интересны подробности – могут ознакомиться с более детальным документом: https://www.usb.org/sites/default/files/327216.pdf

Выводы из него просты: если вы используете USB 3.x устройства с недостаточным экранированием кабелей или самих устройств, то можете получить серьезные проблемы с работой Wi-Fi в диапазоне 2,4 ГГц.

Особенно это касается роутеров, к которым пользователи любят присоединять накопители делая из них мини-медиацентры. Уровень широкополосного шума от USB 3.0 жесткого диска показан на картинке к посту.

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

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

Также кроме Wi-Fi могут страдать и иные беспроводные устройства, например, беспроводные клавиатуры и мыши, также работающие в диапазоне 2,4 ГГц.

Поэтому если ваши устройства ввода вдруг начали вести себя неадекватно, то проверьте, не воткнул ли кто-то рядом с ними USB 3.x устройство.

Чтобы убедиться, что это не теоретическая вероятность, а суровая правда жизни могу привести реальный пример, когда человек столкнулся с подобным эффектом от углового адаптера порта: https://mysku.club/blog/aliexpress/99897.html

При этом на диапазон 5 ГГц устройства USB 3.х никакого негативного влияния не оказывают, на него приходится минимум помех, а следующая гармоника проявит себя уже в диапазоне 7,5 ГГц, но это уже совсем другая история.

23 апреля встречаемся на хардкорном митапе «Метрокластер на отечественном»

Что в программе?
▪️Разбор архитектуры и нюансов технологии метрокластера, особенностей проектирования и реализации
▪️Live-demo работы решения на отечественном оборудовании и ПО

Вы увидите, как ведет себя прикладное ПО при выходе из строя отдельных компонентов кластера и продуктивной площадки целиком.

В составе стенда два набора оборудования:
▪️СХД Аэродиск
▪️Сервер виртуализации Aquarius под управлением zVirt
▪️Коммутатор Qtech

и один набор ПО:
▪️СУБД Postgres Pro под синтетической нагрузкой
▪️Платформа анализа данных Visiology с рабочим местом администратора и руководителя ИТ-инфраструктуры и панелью по анализу данных

Между двумя площадками эмулируется расстояние 60 км. Отслеживать состояние комплекса будет система мониторинга «Пульт».

🗓 Когда?

23 апреля, 16:00

✅ Регистрация

Как внедрить ИИ в бизнес-процессы 

Все говорят об эффективности искусственного интеллекта, а кто скажет, с чего начать? 

Directum собрал опыт известных компаний и включил лучшие практики в один гайд. С его помощью вы сможете:

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

Бонусом получите реальные кейсы, как компании экономят время и деньги с помощью ИИ. 

Успейте скачать гайд Directum, пока они делятся им бесплатно 🔥

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