Сообщество - Лига Сисадминов

Лига Сисадминов

2 236 постов 18 764 подписчика

Популярные теги в сообществе:

23

Кадры: новое поколение слушает Emancipation proclamation. И это прекрасно

Для ЛЛ: Наша молодёжь любит роскошь, она дурно воспитана, она насмехается над начальством и нисколько не уважает стариков. Наши нынешние дети стали тиранами; они не встают, когда в комнату входит пожилой человек, перечат своим родителям. Попросту говоря, они очень плохие.

Проблема российского ИТ , да и не российского тоже, да и не ИТ, просто это в России лучше видно и громче кричат - пропал рынок сбыта, и пропали дешёвые квалифицированные люди. Совсем пропали.

Ряд не-ИТ проектов в РФ опирался на то, что есть дешёвая рабочая сила из N-стана, и есть дешёвые местные проектировщики, бригадиры итд. И они кончились. Совсем.

То есть, 35 лет, с 1990 (если не с 1985) работал естественный отбор.
Работал он очень просто.
1990-2000.
Единственным рабочим способом выживания стало «крутиться». На немногие оставшиеся работать предприятия выстроились очереди, народ массово поехал из умирающих колхозов – в районные центры, из районных – в областные, из областных – в миллионники, из миллионников – в Москву.
Началась сепарация.
На тех, кто готов поднять формальные, неформальные, любые связи (включая межполовые), и уехать туда, где есть работа и перспектива.
И тех, кто не готов. Причины «не готовности» были разные, у кого-то в жизни и так все было неплохо – папа и мама при бизнесе, можно не напрягаться, как-то работать. У кого-то не было яростного желания вырваться любой ценой, хватало на еду, и раз в год съездить в Турцию, и нормально.

Сепарация привела к интересному результату. Из регионов вымыло не столько, и не только квалифицированную рабочую силу, но скорее:
мотивированную рабочую силу, и
мотивирующую рабочую силу.
То есть, в регионах остались не единицы квалифицированных людей, а десятки и сотни, но мотивация «затаскивать» и мотивация «затаскиваться» постепенно заканчивалась.
Люди, умеющие считать, четко понимали, что:
Кризис по образцу 1998, и 2008 года может повториться. В регионах в 2008 году масса людей просто вылетели с работ, в том числе в тепленьком ИТ. В Москве много вылетели, зарплаты просели, кто-то полгода проедал заначку. Но в Москве эта заначка была. В регионах, зачастую, нет.
После 2008, посидев с полгода на картошке с огорода и 6 соток, многие задумались про деньги.
В регионе на линейной позиции в ИТ ты мог (на 2010 год, условно) зарабатывать 15-25 тысяч. При курсе примерно 30, это 500-750$. Кстати, это 50-75 тысяч по текущему курсу.
После всех затрат у тебя оставалось 2-5 тысяч. Квартплата, транспорт, исключительно платная медицина, итд.
При перекате в Москву ты сразу мог уходить на 45-60, на 1500-2000 $. Кстати, это 150-200 к по текущему курсу, то есть не изменилось ничего.
Но, в Москве после вычета аренды (15-20), транспорта (причем, иногда в Моске уже тогда оплачивали проездной) и минимальных расходов (те же 10 к, 300$), у работника оставалось 45-15-10 = 20к. А не 2-5.
Стоит ли говорить, что приток в Москву не останавливался никогда?

Сейчас с этим притоком есть проблема, точнее с его качеством. Причем, проблема многогранная. Или, даже и не проблема.

Проблема первая, квалификация.
Сколько раз сказано, что просмотр видео «берем сперва укропу, ведро воды» - не учит готовить плов.
Сколько раз сказано, что просмотр видео «дети, вот это докер, докер это дети» - не учит понимать, что это, зачем оно, и куда оно. Ну вот докер, да.
Коллеги недавно плакали, громкими слезами, люди пишут в резюме «ставил докер». Если кто не в курсе, то процесс крайне увлекательный и сложный, целых 2 (две) строчки:
sudo apt-get install docker-ce
sudo docker run hello-world

Примечание. В Европе тоже любят писать Python, или Zscaler. Уровень знания - картинку с ним видели, в интерфейс IDE заходили, создать словарь, не говоря уже о загрузке словаря из файла, уже не могут. Fizz buzz не сделают.

Ничего удивительного в этом нет, люди где-то, в 2025 году, под 2019 AD - находят PDC и BDC. Не FSMO, так и пишут – PDC.
То есть, определенная часть поколения после 2000 года рождения, начисто потеряла умение читать, и понимать текст. И до этого у многих были проблемы с пониманием написанного, но, когда человека с 5-10 лет окружает, в основном, видео – он не то что потеряет, он не приобретет умение конспектировать и перерабатывать видео в текст, а текст забивать в МНУ (Межушный нервный узел). На это еще Фейнман жаловался, но соотношение стало хуже, на мой взгляд.

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

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

Поколениям «до 2000 года» - деление, конечно, условное, точнее «поколениям до, примерно, 1980-1985 года рождения» много лет вбивали, что надо «понять, осознать, и покаяться». То есть, если начальник ругается, то нужно стоять и обтекать, вне зависимости от того, прав начальник, не прав. И всегда надо надеяться на светлое будущее. Не подняли зарплату хотя бы по инфляции – ну ничего, потерпим.
Али не выйдем на недоплачиваемые смены? За гроши совестью мужицкой приторговали? Да нет, я по глазам вашим мужицким вижу, что тут зарплатных нет.

До какого-то момента это работало, что в СССР, что в мире. Грамоты, медальки, значки, доска почета – это все работало и работает, но есть нюанс – работает только после закрытия первичных потребностей. В современном мире это своя квартира, своя машина. И только так. Своя квартира пояснений не требует, а своя машина, это не только вывоз тещи на дачу для похорон картошки, это еще и легко реализуемый актив, и в разы лучшая мобильность. Особенно в регионах. Даже в Москве до, примерно, 2010 года. А может и потом.
Сейчас перестало, или стало работать хуже. Genetation Next даже не будет тебе цитировать продолжение поговорки «ты работай дурачок», оно просто уйдет, и от конфликта, из из организации. Рабочая сила стала мобильной, и это хорошо.

НО.
Из того что я слышу в разговорах с приезжающими из РФ, и с оставшимися в РФ бывшими коллегами (опять же, надо заметить, что почти та же ситуация есть и в Европе), что бизнес пока не готов отказаться от двоемыслия и речекряка (Duckspeakers)

Бизнес (говоря про ИТ) прекрасно видит, что нехватку квалифицированной дешёвой силы не закрыть деньгами.
Можно поставить в вакансии заветные 300кк, придут все те же, ничего не знающие, люди.
Можно делать модно, по заграничному, до последнего скрывать размер вилки. И потом плакать, что плак плак, как так, где же люди, почему они все хотят работать за деньги, нас на кратких курсах учили, что мотивация должна быть нематериальной, максимум грамотка. Почему с нас ржут, ведь мы заказали такие красивые блокнотики, а кандидаты при их виде начинают смеяться, ОБИДНО!

Отдельно надо отметить сложности с экономикой некоторых проектов. Проект закладывался, скажем, исходя из того, что 5 программистов по 500к каждому в ФЗП (фонд заработной платы, то есть то, с чего потом возьмут ЕСН, травматизм, потом еще раз НДФЛ, и еще раз возьмут НДС) наработают прибыли на 1.000к в месяц каждый, что окупит и офис, и менеджеров, и макбуки, и еще останется. При 650к проект уже начинает трещать по балансу, при 750к баланс не сходится совсем. И, даже если и сходится, то у любого проекта есть заложенная норма прибыли. Зачем вкладываться в проект с прибылью 10%, когда можно положить деньги в банк под 20%.

Добавляем то, что люди по 500к (до всех налогов) эту катку могут не затащить. То есть не смогут запустить проект. Физически не могут – для одних слишком сложно, другие не могут работать с менеджером, который орет «вы все тут бездари». Минус один программист на проекте означает минус два, потому что, даже если нового тут же найдут, его ж кому-то надо учить. Это базовейшая из баз, мифический человеко-месяц, но кто ж его читал-то?

Добавляем то, что психологически бизнес не готов публично признать, что дешёвые люди кончились.
И часть бизнеса не понимает, как так - техника же работает все быстрее (это правда, все эти авто-дополнения, анализаторы, LLM, co-pilot очень хороши), но почему и раньше на проект надо было 10 человек, и сейчас на проект надо 10 человек.  Нет понимания, почему машзал на 1000 стоек в 2000 году сейчас поместится, пожалуй, в десяток. Почему раньше «огромный» проект занимал 100.000 строк и выполнялся за 5 минут, а сейчас надо 1.000.000 строк кода, и железо в 20 раз мощнее выполняет задачу хорошо если за 5, а скорее за 15 минут.

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

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

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

Удивительно, но труд в РФ не дорожает, если рассматривать в долларе. Как стоил мидл 4000 - 6000$, так и стоит, как стоил сеньор 6000-12000 $, так и стоит. Но нет, мантра 'вы же покупаете в рублях, зачем вам доллары' прочно засела в некоторых головах. Но мидл и сеньор тем и отличаются, что в курсе , что даже в Турции, берут доллары. И что телефон покупается за доллары (или юани). И, слушая эти рассказы, плавно утекают.

Отдельно надо сказать, что в РФ с ростом зарплат в рублях пытаются бороться на самом высоком уровне, но не афишируя этот процесс.
Осенью 2024 менеджмент в РФ пел «сейчас будут сокращения», подразумевая «надо лучше работать, сократим самых отстающих в части ритуальной похвалы меня по утрам».
Сейчас, судя по некоторым крикам боли, оказывается, что сократили или тех, кто реально работал, или тех, кто работал исключительно в части софт-скиллов, то есть много говорил, но ничего не умел.
Новая песня на 2025 – тут у нас обстоятельства, надо потерпеть, повышение, обещанное еще осенью, сдвинуто на следующую осень.

Начинает работать следующий этап сепарации – те, кто готов терпеть, остаются сидеть (но их производительность труда начинает страдать), а те, особенно из Gen Next, кто в этим сказки не верит – берут и уходят. Иногда в никуда, иногда уходят проедать подушку, иногда уходят на мамкины борщи (ТМ), иногда уезжают.
И вот тут бизнес начинает орать – ЧТО Ж ВЫ ДЕЛАЕТЕ, МЫ ВОТ ТАКИМИ НЕ БЫЛИ.
Да были вы, были и остались.

PS.
Полная цитата
General: Now each battalion has a specific code-name and mission. Battalion 5, raise your hands!

General: You will be the all important first defense wave, which we will call "Operation Human Shield".

Chef: Hey, wait a minute...

General: Now keep in mind, 'Operation Human Shield' will suffer heavy losses. But don't lose your spirit men! Stay until the bitter end. Battalion 14?

General: Right, you are 'Operation Get Behind The Darkies'. You will follow Battalion 5 here and try not to get killed for God's Sake. Are there any questions men?

General: Yes Soldier?

Chef: Have you ever heard of the Emancipation Proclamation?

General: I don't listen to hip-hop!
South Park: Bigger, Longer & Uncut

Английский вариант

Русский вариант

Показать полностью 2
23

Народная национальная изба фигвам, а не процессоры уровня пентиум 1

Для лиги лени: чудес не завезли

В новостях проскочило:

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

Прекрасный заголовок, ну что такое восемь лет?

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

Если. Как только, так сразу.
То есть, сначала сделать степпер, и всю обвязку к нему, и не 350, а 28 нм, хотя бы. И производство всей обвязки и расходников.
Потом построить завод, где собрать всю оснастку, в середине которой стоит степпер.
Потом запустить линию, чтобы она давала не 100% брака после первого этапа, а хотя бы 1 (один) годный кристалл в неделю.

И только после этого, может быть, года через три от запуска, сделают .. ну, что-то сделают. По результатам тестов последние образцы Эльбрусов были на уровне Intel Atom – то есть, где-то на уровне современного телевизора.

Что тут сказать. С шумом и криками «вот сейчас заживем» фабрику в Зеленограде начали строить в 2021 году, с обещаниями открыться в 2024. Открыть, видимо, предполагалось саму коробку – стены там, двери, вот это все, вместо Ангстрема – МИЭТ.
Пока новостей "ура фабрика готова" - нет.

28 нм предполагалось делать на рентгеновском литографе. Пока новостей «ура заработало» - не заработало. Конечно, «зато отлично поработали, сделали большой запил задел».

Особенно хорошо это сочетается с подготовкой потока «возвращения детей хороших родителей в родную гавань», ой то есть в 2025 году иностранные топ-менеджеры, особенно из Европы и США, стали чаще проявлять интерес к работе в России. (ура ру)
Им же всем надо где-то работать, чем-то руководить.

И не менее хорошо сочетается с новостями, где в заголовке:
оператор Т2 начал использовать полностью российские SIM-карты «Микрона»
а по тексту статьи:
успешно завершил тестирование
(детали тестирования тоже не приводят)

Обещают, в том числе, MFF, но MFF – это, например, ST Microelectronics SIM-S-IO3-MFF2-2-LP на ARM 32-bit RISC SC300, то есть ST33G1M2M на 80 нм процессе.

Как там было в известном ролике? Витя, они хотя бы из отечественных материалов?

Показать полностью
12

Повышение производительности с использованием LVM Striping

В области управления хранилищами приоритетом является достижение оптимальной производительности дисков. Стремление к более быстрому доступу к данным, уменьшению задержек и повышению количества операций ввода-вывода (I/O) и пропускной способности привело к использованию передовых техник. Одной из таких является LVM Striping (полосование), мощная функция менеджера логических томов (LVM), которая существенно повышает производительность дисковых томов.

Линейный (Linear) LVM против LVM Striping:

1.1 — Линейный LVM:

Линейная конфигурация, являющаяся стандартным подходом для LVM, подразумевает последовательное добавление нескольких физических томов (дисков) в группу томов (Volume Group). Данные последовательно записываются на эти диски: сначала заполняется один диск, затем следующий, и так далее.

Повышение производительности с использованием LVM Striping Системное администрирование, Linux, Shell, IT, Исследования, Сервер, Длиннопост

Хотя линейный LVM прост и удобен для расширения хранилищ, он не полностью раскрывает потенциал параллельной обработки и увеличения общей пропускной способности.

1.2 — LVM Striping (Полосование):

Напротив, LVM Striping представляет собой более продвинутый подход, при котором данные распределяются одновременно по нескольким физическим томам. Это создает логический том, охватывающий сразу несколько дисков, что позволяет осуществлять параллельные операции чтения и записи. В результате значительно повышается производительность, что делает LVM Striping особенно привлекательным для систем с высоким уровнем нагрузки ввода-вывода.

Повышение производительности с использованием LVM Striping Системное администрирование, Linux, Shell, IT, Исследования, Сервер, Длиннопост

Процесс создания полос:

  1. Создание полос:

  • Данные разделяются на сегменты («полосы»).

  • Каждая полоса записывается на отдельный диск в составе логического тома.

2. Параллельная запись полос:

  • Полосы записываются параллельно на несколько физических томов (дисков).

3. Равномерное распределение:

  • Полосы равномерно распределены по дискам, предотвращая появление узкого места (bottleneck).

4. Увеличение IOPS и пропускной способности:

  • Благодаря параллельной записи полос LVM Striping существенно увеличивает общую производительность и пропускную способность логического тома.

1.3 — Пример использования:

Рассмотрим пример с тремя дисками, каждый из которых обеспечивает пропускную способность 125 МБ/с:

  • При использовании LVM Striping суммарная производительность составит 375 МБ/с.

  • В случае же с линейным LVM, производительность останется равной 125 МБ/с, вне зависимости от количества добавленных дисков.

Настройка Linear LVM и Striping LVM:

В этом разделе мы создадим две группы томов (Volume Groups, VG): одну линейную, вторую — с полосованием, каждая с использованием трёх дисков. Затем создадим логические тома (Logical Volumes, LV), отформатируем и смонтируем их.

2.1 — Исходные данные:

  • Сервер: AWS EC2 instance типа m4.10xlarge

  • EBS-диски: 6 штук по 20ГБ (тип GP3, 3000 IOPS, 125MiB/s пропускная способность каждый)

  • ОС: Amazon Linux 2

Просмотр подключенных дисков:

# lsblk

Повышение производительности с использованием LVM Striping Системное администрирование, Linux, Shell, IT, Исследования, Сервер, Длиннопост

2.2 — Создание групп томов (VG):

Создадим две группы томов:

# vgcreate vg_linear /dev/sdb /dev/sdc /dev/sdd
# vgcreate vg_striping /dev/sde /dev/sdf /dev/sdg

Повышение производительности с использованием LVM Striping Системное администрирование, Linux, Shell, IT, Исследования, Сервер, Длиннопост

# vgs

Повышение производительности с использованием LVM Striping Системное администрирование, Linux, Shell, IT, Исследования, Сервер, Длиннопост

2.3 — Создание линейного логического тома (Linear LVM):

# lvcreate -l 100%FREE -n lv_linear vg_linear

Повышение производительности с использованием LVM Striping Системное администрирование, Linux, Shell, IT, Исследования, Сервер, Длиннопост

Параметры:

  • -l 100%FREE — задействовать весь доступный объем VG.

  • -n lv_linear — имя логического тома.

  • vg_linear — целевая группа томов.

2.4 — Создание логического тома с полосованием (Striping LVM):

# lvcreate -l 100%FREE -i 3 -I 64k -n lv_striping vg_striping

Повышение производительности с использованием LVM Striping Системное администрирование, Linux, Shell, IT, Исследования, Сервер, Длиннопост

Параметры:

  • -l 100%FREE — задействовать весь объем VG.

  • -i 3 — количество полос (равно числу дисков).

  • -I 64k — размер полосы.

  • -n lv_striping — имя логического тома.

  • vg_striping — целевая группа томов.

2.5 — Проверка созданных LV:

Проверка линейного LV:

# lvdisplay -m /dev/vg_linear/lv_linear

Повышение производительности с использованием LVM Striping Системное администрирование, Linux, Shell, IT, Исследования, Сервер, Длиннопост

Проверка LV с полосованием:

# lvdisplay -m /dev/vg_striping/lv_striping

Повышение производительности с использованием LVM Striping Системное администрирование, Linux, Shell, IT, Исследования, Сервер, Длиннопост

Здесь мы можем увидеть различные детали наших настроек.

2.6 — Форматирование и монтирование LV:

# mkfs.xfs /dev/vg_linear/lv_linear

# mkfs.xfs /dev/vg_striping/lv_striping

# mkdir /mnt/linear

# mkdir /mnt/striping

# mount /dev/vg_linear/lv_linear /mnt/linear/

# mount /dev/vg_striping/lv_striping /mnt/striping/

# df -h

Повышение производительности с использованием LVM Striping Системное администрирование, Linux, Shell, IT, Исследования, Сервер, Длиннопост

LV успешно смонтированы.

3 — Тестирование производительности LV (benchmark):

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

# yum install fio -y

3.1 — Тестирование линейного LV:

Чтобы сравнить LV, мы будем использовать файл конфигурации FIO, который поможет нам генерировать трафик на 400м:

# cat fio_config-1.fio

[global]

ioengine=libaio

runtime=60

time_based

direct=1

rw=write

size=10G

bs=512K

rate=400M

numjobs=16

[job1]

filename=/mnt/linear/testfile

Запуск тестирования с созданным конфигом:

# fio fio_config-1.fio

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

# iostat -xdmt 2

Повышение производительности с использованием LVM Striping Системное администрирование, Linux, Shell, IT, Исследования, Сервер, Длиннопост

Видим, что используется только один диск xvdb со скоростью 125 МБ/с.

Ту же картину нам демонстрирует и fio:

Повышение производительности с использованием LVM Striping Системное администрирование, Linux, Shell, IT, Исследования, Сервер, Длиннопост

Операции записи были выполнены исключительно на одном диске.

3.2 — Тестирование LV с полосованием:

Теперь снова запустим fio, но изменим параметр filename в файле конфигурации:

filename=/mnt/striping/testfile

Запускаем iostat:

Повышение производительности с использованием LVM Striping Системное администрирование, Linux, Shell, IT, Исследования, Сервер, Длиннопост

Все три диска работают параллельно, суммарная скорость равна 375 МБ/с (125 x 3).

Аналогичную картинку нам демонстрирует и fio:

Повышение производительности с использованием LVM Striping Системное администрирование, Linux, Shell, IT, Исследования, Сервер, Длиннопост

Вывод:

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

Используйте LVM Striping, чтобы раскрыть потенциал параллельной обработки данных и вывести производительность дисковой подсистемы на новый уровень.

Показать полностью 14
33
Вопрос из ленты «Эксперты»

Убегает время на PDC

Имеется AD два КД основной и резервный, NS и NS1 соответственно. Оба КД крутятся на virtualbox, гипервизоры физически на разных машинах. Всё это тихо-мирно работало 3 года пока в один прекрасный момент, после суточного блэкаута система выдала мне "время на КД не синхронизировано". С хостом виртуалки не синхронизируется, VB по моему не очень это умеет. Прописал в GPO конкретно для PDC, ситуация не изменилась. Снес к херам все ветки реестра касающиеся службы времени, прописал параметры вручную, ситуация не изменилась. Через какой-то отрезок времени PDC сообщает: "Служба времени обнаружила разницу во времени, превышающую 5000 мсек. в течение 900 сек..." и соответственно отключается из процесса.

проверяем время на PDC

Убегает время на PDC Спроси Пикабу, Вопрос, Без рейтинга, Windows server, Active Directory, Время, Длиннопост

отстают

w32tm /resync && w32tm /stripchart /computer:ru.pool.ntp.org и наблюдаем следующую картину

Убегает время на PDC Спроси Пикабу, Вопрос, Без рейтинга, Windows server, Active Directory, Время, Длиннопост

на резервном КД время идет точно

Убегает время на PDC Спроси Пикабу, Вопрос, Без рейтинга, Windows server, Active Directory, Время, Длиннопост

ну почти

а вот вид с резервного КД на PDC

Убегает время на PDC Спроси Пикабу, Вопрос, Без рейтинга, Windows server, Active Directory, Время, Длиннопост

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

Что с этим делать а? Переводить PDC на другую машину или можно починить.

з.ы. админ не настоящий клавиатуру на стройке нашел.

UPD: специально для не умеющих читать для советчиков замены батарейки и синхронизации с хостом.

Убегает время на PDC Спроси Пикабу, Вопрос, Без рейтинга, Windows server, Active Directory, Время, Длиннопост

конфиг PDC

Убегает время на PDC Спроси Пикабу, Вопрос, Без рейтинга, Windows server, Active Directory, Время, Длиннопост

гипервизор

Показать полностью 5
19

Влияние максимального размера I/O-запросов на производительность систем Linux

В области оптимизации производительности Linux важнейшим фактором является производительность дискового ввода-вывода (I/O), которая существенно влияет на общую эффективность системы. Одним из ключевых параметров, влияющих на производительность дискового ввода-вывода, является максимальный размер I/O-запроса, определяемый параметром max_sectors_kb. Понимание и настройка этого параметра могут привести к значительному улучшению производительности системы. В этой статье мы рассмотрим понятие максимального размера I/O, его важность в системах Linux, а также его влияние на производительность в целом.

Понимание максимального размера I/O (max_sectors_kb)

Параметр max_sectors_kb определяет максимальный размер отдельного I/O-запроса в килобайтах. Он устанавливает объём данных, который может быть передан в рамках одного I/O-запроса. Значение параметра max_sectors_kb ограничено логическим размером блока файловой системы и аппаратными возможностями устройства хранения данных. Оно не может быть меньше логического размера блока, делённого на 1024, и не должно превышать значение параметра max_hw_sectors_kb, который является параметром только для чтения и показывает максимально поддерживаемый аппаратурой размер запроса.

Минимальное значение = max(1, logical_block_size/1024) 

Максимальное значение = max_hw_sectors_kb

Примечание: Максимальный размер I/O в Linux преимущественно применим к ядрам версии 4.x и выше. Рекомендуется проверить это в конкретном ядре вашей системы. Хотя впрочем очевидно - если у вас не какой-нибудь embedded, то ядро скорее всего будет выше 5.x

Важность в системах Linux

В Linux параметр максимального размера I/O существенно влияет на эффективность чтения и записи данных с устройств хранения. Он оказывает влияние на следующие аспекты производительности:

1. Баланс между пропускной способностью и задержками:

  • Пропускная способность (Throughput): Крупные размеры I/O-запросов увеличивают общую пропускную способность ввода-вывода за счёт обработки больших блоков данных за одну операцию. Это снижает накладные расходы на обработку множества мелких запросов, особенно эффективно при работе с последовательными потоками данных (видеостриминг, резервные копии баз данных).

  • Задержки (Latency): В то время как большие размеры I/O-запросов могут повысить пропускную способность для больших наборов наборов, они также могут увеличить задержку отдельных операций. Это происходит потому, что более крупные запросы требуют больше времени для завершения. Поэтому необходим баланс между улучшением производительности и допустимым уровнем задержек, особенно в чувствительных к задержкам интерактивных или real-time приложениях. В таких случаях предпочтительнее меньшие размеры запросов.

2. Использование CPU:

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

3. Использование памяти:

  • Максимальный размер I/O влияет на объём выделяемой памяти под буферы ввода-вывода, что также отражается на общем использовании памяти системой.

Факторы, влияющие на максимальный размер I/O

Есть несколько факторов, которые влияют на максимальный размер запросов в Linux:

  • Аппаратные ограничения: Значение max_sectors_kb не должно превышать аппаратные возможности накопителя (значение параметра max_hw_sectors_kb). Превышение аппаратного лимита может привести к ошибкам или снижению производительности.

  • Драйверы устройств: Драйверы контроллеров хранения и накопителей могут задавать свои лимиты на размер запросов.

  • Ограничения файловых систем: У разных файловых систем разные лимиты на размер запроса ввода-вывода.

  • Параметры ядра Linux: Настройки блочных устройств ядра влияют на размер запроса.

Бенчмаркинг и мониторинг

Для определения оптимального размера I/O-запросов необходимо проводить тестирование (бенчмарки) и мониторить показатели производительности (например, с помощью утилиты iostat).

Рекомендуется учитывать:

  • Red Hat советует, чтобы значение max_sectors_kb было кратно оптимальному размеру I/O и внутреннему размеру блока стирания устройства. Если таких данных нет, рекомендуется выставить значение, совпадающее с логическим размером блока устройства.

  • Характеристики рабочей нагрузки: разные приложения выигрывают от разных размеров I/O.

  • Особенности накопителя: HDD и SSD имеют разные оптимальные диапазоны размеров I/O.

  • Ресурсы системы: доступная память и мощность CPU влияют на выбор оптимального размера I/O.

Практические аспекты настройки

Для настройки max_sectors_kb используется команда:

/sys/block/{device}/queue/max_sectors_kb

Например:

echo 256 | sudo tee /sys/block/sda/queue/max_sectors_kb

Данная команда устанавливает максимальный размер запроса в 256 КБ для диска /dev/sda. Перед изменениями желательно протестировать настройки на тестовой системе во избежание негативного влияния на производительность или стабильность системы.

Изменения параметра действуют только до перезагрузки системы. Чтобы изменения сохранялись, добавьте команду в rc.local или настройте сервис для применения параметров при загрузке.

Практическое исследование

Рассмотрим практический сценарий. Создадим лабораторную среду на Linux-сервере и проверим производительность диска. Нагрузку (IOPS) будем генерировать с помощью инструмента fio, а мониторинг производительности проводить с помощью утилиты iostat. Наша задача — оценить влияние параметра max_sectors_kb на производительность системы.

Среда для тестирования:

  • Тип EC2-инстанса: c5.12xlarge

  • EBS-том:

  • тип: GP3

  • размер: 20 GiB

  • IOPS: 3000

  • пропускная способность: 750 MB/s

  • Операционная система: Amazon Linux 2

Проверка дисков и установка fio

Для начала проверим доступные диски:

Влияние максимального размера I/O-запросов на производительность систем Linux Системное администрирование, Компьютерное железо, Linux, Исследования, Производительность, Сервер, Длиннопост

Мы будем создавать нагрузку на диск nvme1n1 при помощи утилиты fio и параллельно мониторить производительность диска, в частности показатель IOPS. Если fio не установлен, используйте команды ниже:

Для Amazon Linux:

sudo yum install -y fio

Для Ubuntu:

sudo apt-get install -y fio

Запуск теста

Откройте два терминала одновременно:

Терминал 1: Генерируем нагрузку:

sudo fio --filename=/dev/nvme1n1 --rw=read --bs=256K --ioengine=libaio --direct=1 --name=volume-initialize

Терминал 2: Мониторим диск:

iostat 1 -d /dev/nvme1n1

Обратите внимание, что в команде fio мы задали размер запроса 256 KiB.

Влияние максимального размера I/O-запросов на производительность систем Linux Системное администрирование, Компьютерное железо, Linux, Исследования, Производительность, Сервер, Длиннопост
Влияние максимального размера I/O-запросов на производительность систем Linux Системное администрирование, Компьютерное железо, Linux, Исследования, Производительность, Сервер, Длиннопост

Наблюдения

На первом скриншоте видно, что утилита fio генерирует 1082 IOPS, однако утилита iostat показывает примерно 2164 IOPS (то есть в два раза больше).

Причина различий

Чтобы выяснить причину этого несоответствия, проверим значение параметра max_sectors_kb:

cat /sys/block/nvme1n1/queue/max_sectors_kb

Влияние максимального размера I/O-запросов на производительность систем Linux Системное администрирование, Компьютерное железо, Linux, Исследования, Производительность, Сервер, Длиннопост

Объяснение:

Инструмент fio создавал IOPS с размером 256 KiB, а max_sectors_kb был установлен на значение 128 KiB. В результате ядро Linux разбивало каждый запрос на два меньших запроса по 128 KiB каждый (256 KiB = 128 KiB × 2). Именно поэтому количество операций, регистрируемых iostat, было в два раза больше, чем указывал fio (1082 × 2 = 2164).

Важно: Увеличение числа запросов из-за неправильно настроенного max_sectors_kb может негативно повлиять на производительность сервера и привести к троттлингу производительности диска (например, EBS-тома), если число операций превышает базовый уровень IOPS.

Проверка максимального аппаратного лимита max_hw_sectors_kb

Проверим максимальное значение I/O, которое поддерживает наш сервер:

cat /sys/block/nvme1n1/queue/max_hw_sectors_kb

Влияние максимального размера I/O-запросов на производительность систем Linux Системное администрирование, Компьютерное железо, Linux, Исследования, Производительность, Сервер, Длиннопост

Результат: наш сервер поддерживает максимальный размер I/O-запроса в 256 KiB.

Попытка увеличения max_sectors_kb

Попробуем увеличить значение до 512 KiB:

echo 512 | sudo tee /sys/block/nvme1n1/queue/max_sectors_kb

Влияние максимального размера I/O-запросов на производительность систем Linux Системное администрирование, Компьютерное железо, Linux, Исследования, Производительность, Сервер, Длиннопост

Результат: Мы получили ошибку «Invalid argument» («Недопустимый аргумент»), так как указали значение, превышающее аппаратный лимит max_hw_sectors_kb.

Теперь установим допустимое значение 256 KiB:

echo 256 | sudo tee /sys/block/nvme1n1/queue/max_sectors_kb

Влияние максимального размера I/O-запросов на производительность систем Linux Системное администрирование, Компьютерное железо, Linux, Исследования, Производительность, Сервер, Длиннопост

Результат: Значение успешно изменено на 256 KiB.

Повторный запуск теста fio

Повторим тест командой:

sudo fio --filename=/dev/nvme1n1 --rw=read --bs=256K --ioengine=libaio --direct=1 --name=volume-initialize

Влияние максимального размера I/O-запросов на производительность систем Linux Системное администрирование, Компьютерное железо, Linux, Исследования, Производительность, Сервер, Длиннопост
Влияние максимального размера I/O-запросов на производительность систем Linux Системное администрирование, Компьютерное железо, Linux, Исследования, Производительность, Сервер, Длиннопост

Результат: После изменения параметра max_sectors_kb количество операций IOPS, отображаемое fio и iostat, совпало.

Заключение:

Максимальный размер I/O-запроса (max_sectors_kb) является мощным инструментом для тонкой настройки производительности дисковой подсистемы в Linux. Правильно подобранное значение позволяет оптимизировать производительность ввода-вывода и снизить нагрузку на CPU, однако следует учитывать возможное увеличение задержек и аппаратные ограничения. Любые изменения параметров производительности следует предварительно тестировать и внимательно анализировать перед внедрением в продуктивную среду. Это гарантирует стабильность работы системы и её оптимальную производительность в различных сценариях.

Показать полностью 9
4

Пора прощаться с VMware by Broadcom. История в нескольких частях. Часть 2

Для лиги лени: про бывшую VMware, теперь VMware by Broadcom. Чего было и чего ждать

Часть 1. Чего и почему ждать.

Часть 2. Fast start. Литература и сайты для тех, кто вляпается в это легаси.

Часть 3. Прочее.

1.1 Пока переписывалась статья, вышло обновление-
8.0 Update 3e 24674464 , с обещаниями снова выдавать ESXi free, еще более урезанную.
Спасибо конечно, и на том.

Пора прощаться с VMware by Broadcom. История в нескольких частях. Часть 2 Импортозамещение, Vmware, Ссылка, Windows, Программа, Длиннопост

1. 2 Не дописанное из первой части

Продукты фирмы VMware не были как-то особо популярны в РФ. Так, по мелочи.
Пара мелких банков, какие-то сотовые и небольшие телеком операторы, разорившаяся авиакомпания, пара фирм по розничным продажа бытовой химии, облачные провайдеры, итд. Короче, все те, кто не мог себе позволить купить нормальный Azure Stack (Azure Stack HCI, сейчас Azure Local), или сидел на таком дремучем легаси, что виртуализация у них была уже, конечно, не механическая, и не ламповая, но серверы приходилось или ставить краном, или возить на специальном лифте. Оборот и прибыль VMware в РФ (от мировой) была в районе статистической погрешности, от 0.1 до 1%, поэтому ее уход из РФ заметили только те, кто работал (скорее, не работал) в облаке МТС в 2024 году.
Такие, во всех отношениях отсталые продукты, как:
VMware NSX
Omnissa Horizon (ранее Horizon View, VMware VDI, VMware View)
VMware Cloud Director
VMware Cloud Foundation

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

Пора прощаться с VMware by Broadcom. История в нескольких частях. Часть 2 Импортозамещение, Vmware, Ссылка, Windows, Программа, Длиннопост

Ит отдел готовится к безболезненному уходу от VMware, и внедрению в критическую

Если же они этого не сделали, то возникает интересный тройной юридический казус.
Во первых, по лицензионному соглашению, заказчик имеет право на обновления только в период действия подписки на поддержку. Срок подписки обычно был три года, вся подписка из 2021 закончилась в 2024, а местами и в 2022, поэтому вопрос законности покажет любой аудит.
Во вторых, и это гораздо интереснее, очень много сотовых операторов , банков и так далее «в целом» отнесены к КИИ. Соответственно, в их системах должны быть установлены обновления безопасности, скачанные с официального сайта, и проверенные соответствующими органами.
В частности:
Обновление VMware Tools, Идентификатор обновления: TO1965, Вендор: VMware Inc., ПО: VMware Tools .
С вендором ошибка, до ФСТЕК за 2 года не дошло, что это теперь Broadcom, фирмы VMware Inc больше нет. Там, на сайте, и с обновлениями самого ESXi проблема, последнее протестированное обновление 8.0b-21203435 для 8.0 из 2023. Но уязвимости описаны, BDU:2024-01809 или BDU:2025-02354, вместе с советами «выкручивайтесь сами», то есть, конечно, не так, цитата:

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

Интересно, что когда зарубежная проприетарщина много лет поставляет в РФ проверенные и годные продукты это одно, а захват ядра, базы из баз , практически всего опенсорса кликой сумасшедшего финна из агрессивного блока НАТО, это другое.
Ну да ладно, а то так окажется, что исходники Windows 20 лет назад отдали, кому положено, и что Windows с 1996 до 2004 года неплохо работал в системе управления вооружением USS Yorktown (DDG-48/CG-48, программа Navy's Smart Ship program - на 2*27 Pentium Pro)

И в третьих, это рекомендации «переходить на российское шифрование и не использовать то, о чем говорить нельзя, из трех букв».
Как использовать российское этцамое для обновления по https, если с той стороны не в курсе про ГОСТ, и как не использовать этцамое, если с той стороны и обновление, и документация, закрыты для РФ?

Пора прощаться с VMware by Broadcom. История в нескольких частях. Часть 2 Импортозамещение, Vmware, Ссылка, Windows, Программа, Длиннопост

Вы находитесь здесь

Но, к теме.

Fast start. Литература и сайты для тех, кто вляпается в это легаси.

Сразу скажу: если вы унаследовали «это», то можете забыть про какую-то литературу на русском.

По теме выходило ровно 3(три) книги на русском, от 1 (одного)  автора.

Михаил Михеев: Администрирование VMware vSphere из 2010 года.
Михаил Михеев: Администрирование VMware vSphere 4.1 из 2011 года.
Михаил Михеев: Администрирование VMware vSphere 5 из 2012 года.

На этом ВСЁ.
ВООБЩЕ ВСЁ.

Больше литературы, кроме выгрузок лекций, переводов статей и курсов «в пересказе по мотивам» не было.
Русификация портала vmwarelearning.com осталась где-то там же, в 2012 году, с тех пор все куда-то ехало, ехало, и переехало.
Еще есть VMware vSphere 4,5,6,7.0 ESXi - записки на манжетах от Максима Мошкова.

Маст рид. Серия Deep dive

Duncan Epping – vSphere 6.0 U2 HA Deepdive
VMware vSphere 6.5 Host Resources Deep Dive by Frank Denneman and Niels Hagoort
Rubric, Clustering Deep Dive - VMware vSphere 6.7 Clustering Deep Dive Kindle Edition by Frank Denneman (Author), Duncan Epping (Author), Niels Hagoort (Author)
VMware vSAN 6.7 U1 Deep Dive by Cormac Hogan (Author), Duncan Epping (Author)
VMware vSAN Deep Dive 7.0 Update 3.
Storage Design and Implementation in vSphere 6: A Technology Deep Dive (VMware Press Technology) 2nd Edition, Kindle Edition by Mostafa Khalil (Author)
Заполировать: VMware vSphere PowerCLI Reference. Automating vSphere Administration | Boren Matt, Graf Brian

Парочка сайтов:
Cody Hosterman
Duncan Epping
Frank Denneman
Vladan Seget
Niels Hagoort и https://blogs.vmware.com/vsphere/author/nhagoor ;
Luc Dekens , в том числе virtuallyGhetto

В обязательном порядке должна быть прочитана книга по сетям.
Не какой-то там курс от «аналоговнетных русских курсов и русских авторов», а только родная Cisco. И только такая:
Cisco CCENT/CCNA ICND1 100-101 Official Cert Guide  Academic Edition - by WENDELL ODOM, CCIE NO.
Если в каком-то сообществе, группе, все равно где, вам предлагают читать Олиферов вместо Cisco Press - БЕГИТЕ ГЛУПЦЫ.
После того, как вы прочитаете все вышеперечисленное, можно идти сюда за второй порцией литературы и статей.

Надо обязательно добавить в избранное, первый месяц с этих сайтов лучше не вылезать:
VMware Compatibility Guide (HCL)
VMware ESXi Patch Tracker
VMware vSphere 8.0 Release Notes - раньше жили на https://docs.vmware.com/en/VMware-vSphere/8.0/ , почему-то копия живет тут, на adobecqms.
Community Network Driver for ESXi Documentation , раньше это называлось flings  и жило тут.

Добавляются учебные стенды. Бесплатные! VMware Hands-on Labs - https://hol.vmware.com/

Добавляются сети. Придется биться насмерть с сетевиками, и с любителями русской сетевой литературы, где LAG считается третьим лучшим изобретением человечества, сразу после описанного в Бытие 38:9 и Левит (18:22).
Читать заметку: John Nicholson - As I lay in bed I can’t help but think…. LAG/LACP/MLAG/Bonding links to hosts is a bad idea for anything you care about that much. (A thread) – тут могла быть ссылка на вроде еще запрещенных в РФ любителей 140 знаков, и вот эту статью - LACP and vSphere (ESXi) hosts: not a very good marriage.

Дальше остаются мелочи.
Работа с хостом через Direct Console User Interface (DCUI), через ssh, и powercli .
Регулярный Левит (18:22), то есть перезапуск агентов управления - Restarting the Management agents in ESXi (1003490) , и еще четыре статьи. Первая, вторая, третья, четвертая.
И, просто списком, уже совсем мелкое.
Esxtop, code capture, vsish (VMkernel Sys Info Shell), RVTools, VMware ESXi SCSI Sense Code Decoder

Для начала хватит. Потом пойдет всякая рутина - Allow unsupported CPUs,Side-Channel Aware Scheduler v2 (SCAv2),  Performance Best Practices for VMware vSphere 8.0, Best Practices for Performance Tuning of Latency-Sensitive Workloads in vSphere VMs, и прочая скука скучная.

Подводя итог.
Как легко прочитать в интернете, ESXi и прочие продукты VMware вокруг него – это жалкое проприетарное подобие Linux \ KVM \ XEN \ CEPH \ OVN, и еще сотни «замещающих» продуктов, по непонятным причинам совокупно (с учетом стоимости людей и требований к оборудованию) стоящее дешевле в пересчете на 3 года. Исключение - если у вас люди бесплатные, помещение бесплатное, и никаких требований к SLA нет. Давно списанное оборудование на балконе, например, которое может упасть только вместе с балконом, а зимой греет весь подъезд всеми 8 ядрами на сокет (единственный).
Учиться работать с этим, конечно, не стоит. Рынок труда для этих продуктов уже ограничен «золотой тысячей кровавого энтерпрайза», то есть, суммарный платежеспособный спрос будет падать и падать. Всегда останутся организации, в поисках высококвалифицированных низкооплачиваемых кадров, почему-то не могущие найти кадры на открытом рынке.
Да и учиться там особо нечему – как большая часть проприетарных продуктов, он еще недавно был сделан так, чтобы, в основном, работать.
Если не работает, что бывало, то дать возможность собрать огромный дамп логов для техподдержки. Конечно, и тут все нехорошо. Последние лет 5 и в эту разработку прокрались криворукие, вместе с идеей «давайте тестировать новый код на пользователях».
Хуже всего в VMware в РФ – это отсутствие комьюнити. Два русских сообщества, входящие в Virtual maining user group, причем на треть состава сидящие в третьем сообществе, по нелицензионным версиям VMware. Одно мертвое сообщество по NSX, такое же мертвое по Amazon Elastic VMware Service. Одно более-менее живое сообщество по vSAN, и просто ужас под названием «Сообщество по Азии». Помогут, в лучшем случае, в группе по vSAN. Вместо остальных достаточно бота с случайными сообщениями «гуглить пробовали», «это все есть в документации», или "что в логах".

Как же хорошо, что есть Reddit, LLM и форумы самого Broadcom.

PS.
Как мне напомнили рецензенты, есть один крохотнейший плюс - то, что vGate умер на линейке 7. Это снизило глобальное потепление в России на 0.1 градуса, и уровень смога в Москве на 0.2%.

Показать полностью 3
3

Помощь в настройке AT-FS750/48

Я добавляю второй коммутатор в шкаф. Беру связь с первым через транк.
Прописываю, беря конфиг с первого.
interface vlan1

member 48

name "Default VLAN"

untagged 48

interface vlan81

member 4-47,49-50

name voice

interface vlan82

member 4-47,49-50

name lan

untagged 4-47

interface FastEthernet1/38

PVID 82

storm-control broadcast

storm-control multicast

storm-control DLF

Почему при подключении к порту обычного свича на 8 портов за 1000 рублей ничего работает. Vlan трафик не ходит, пк не получают адрес.

С телефонами такая же история. Если подключить yealink и пк к нему, то все ок.
С телефонами grandstream такое не проходит.

Откопал в помойке cisco и прописал
interface gigabitethernet2

switchport trunk allowed vlan add 81

switchport trunk native vlan 82

Тоже самое.
Объясните пожалуйста тупому, где моя ошибка

Показать полностью
Отличная работа, все прочитано!