>>13757
Обсервабилити (observability) и мониторинг имеют схожие цели, но концептуально и практически они различаются.
1. Мониторинг

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

Вы предопределяете метрики и логи, которые важно собирать.
Система настроена на оповещение о конкретных нарушениях или аномалиях (например, CPU выше 80% или доступность сервиса ниже 99%).
Это реактивный подход: вы узнаёте о проблеме, когда она уже произошла и соответствует заданным условиям.

2. Обсервабилити

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

Неопределённость: Обсервабилити позволяет исследовать поведение системы в новых или неожиданных ситуациях (например, почему новая версия приложения вдруг замедлилась на некоторых запросах?).
Комплексность: Собираются три ключевых типа сигналов:
Метрики — количественные показатели (время отклика, ошибки).
Логи — текстовые записи событий и операций.
Трейсы — информация о прохождении запросов через распределённую систему.
Инструменты анализа: обсервабилити-платформы предоставляют средства для гибкого и интерактивного анализа (поиск корреляций, построение запросов, исследование зависимостей).
Проактивный подход: это помогает не только диагностировать проблемы, но и предотвращать их, анализируя слабые места до инцидентов.

3. Почему обсервабилити ≠ просто объединение?

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

Обсервабилити делает упор на контекст и связь между данными, предоставляя инструменты для динамического исследования системы.
Это не просто сбор и визуализация данных, а создание платформы для поиска и объяснения любых системных аномалий.
Например, обсервабилити-системы (такие как Honeycomb, Datadog, или Grafana Tempo) помогают видеть, как и почему что-то происходит, связывая данные между разными уровнями системы.

4. Пример:

Мониторинг:

Если падает API, вы получите алерт: "Доступность ниже 99%".
Вы видите метрику, указывающую на проблему, но чтобы выяснить причину, нужно рыться в логах и трейсах вручную.

Обсервабилити:

Вы задаёте системе вопрос: "Почему задержка API возросла для запросов из региона X?"
Она покажет вам коррелирующие события, зависимости между сервисами, аномалии в трейсах и даже, возможно, причину проблемы.

5. Заключение

Обсервабилити — это больше, чем просто "модное слово" или объединение данных. Это подход, позволяющий строить системы, которые можно эффективно исследовать и понимать. Мониторинг же — лишь часть этого подхода, нацеленная на слежение за уже известными параметрами. Вместе они составляют полноценную стратегию обеспечения стабильности и надёжности систем.

>>14824
Как AD, mikrotik и ip телефония относятся к devops? Или я тебя неправильно понял?

Devops это про ci/di, кубы, автоматизация и пайплайны, git (тут очевидный gitlab), IaC (очевидный terraform и andible), zabbix это ок, но я бы ещё добавил prometheus, само собой jenkins. Ещё почему-то все забывают про nosql, брокеры сообщений и балансировщики.

Можно добавить докер, линукс и сети, но, например, в моей компании девопсы вообще не трогают сети а работаю я в МЯСКОТ, так что в определенной мере это стандарт индустрии. Если видишь такое в требованиях, то это моветон и лучше скипнуть, так как противоречит самой философии devops ведь это именно про идеологию, а не какую-то конкретную специальность.

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

>>14808

>Хотя если ты сисадмин с опытом, то опыт котируется

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

>поэтому можно сразу на мидла откликаться.

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

>>14406

>3 год сосет бибу за 70к в ДС1

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

Мимо проходил, попался ваш тред. Выглядит как эхо-камера админов из ООО ПромСтройБетон без негатива . Если метите в девопсы, то учите хотя бы актуальный стек, если в тестеры, то зубрите теорию тестирования, набивайте руку на чек-листах, тест-кейсах и отчетах о тестировании, дальше в зависимости от того направления, куда вы хотите попасть. На количество откликов даже не смотрите, внутренние процессы HR в крупных компаниях позволяют поработать с кандидатом, который был 3001-ый по отклику. Могу ответить на вопросы по существу, 280к, AQA, финтех.

>>17721
Для прописывания базовой станции (BS) на RNC (Radio Network Controller) и BSC (Base Station Controller) необходимо настроить соответствующие параметры и компоненты на каждом из контроллеров. Оба этих устройства управляют базовыми станциями, но с некоторыми различиями в архитектуре.

### 1. RNC (Radio Network Controller)

RNC — это часть сети, управляющая радиочастотными ресурсами и управлением соединениями в WCDMA (UMTS). В нем управляются несколько Node B (базовых станций).

Шаги для настройки базы станции на RNC:

1. Подключение Node B к RNC:
- На RNC необходимо создать объект для базовой станции Node B.
- Укажите параметры подключения (например, IP-адреса, идентификаторы и протоколы для связи между RNC и Node B).

2. Конфигурация и активация базовой станции:
- В настройках RNC укажите параметры базовой станции, такие как:
- Идентификатор Node B.
- Каналы и частоты.
- Ресурсы для передачи и приема.
- Параметры обработки сигналов.

3. Конфигурация каналов связи:
- Настройте каналы управления и передачи для базовой станции.
- Укажите параметры для голосовых и данных-соединений.

4. Подключение к внешним сетям (например, к SGSN):
- Подключите RNC к системе управления мобильной сетью (например, к SGSN), чтобы передавать данные о пользователях и управлять состоянием соединений.

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

### 2. BSC (Base Station Controller)

BSC — это контроллер, который управляет множеством базовых станций в GSM-сетях. Он координирует работу базовых станций и управляет ресурсами связи.

Шаги для настройки базы станции на BSC:

1. Создание связи между BSC и базовой станцией:
- Для каждой базовой станции создайте соответствующий объект в конфигурации BSC.
- Укажите параметры связи между BSC и базовой станцией (например, каналы управления, IP-адреса и т. д.).

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

3. Подключение к другим компонентам сети:
- Настройте связи между BSC и другими компонентами сети, такими как MSC (Mobile Switching Center), GGSN (Gateway GPRS Support Node), SGSN и другими элементами инфраструктуры.

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

5. Тестирование:
- Проведите тесты для проверки работы базовых станций, включая проверку качества сигнала и корректности связи.

### Заключение

Процесс прописывания базовой станции зависит от типа сети (UMTS для RNC или GSM для BSC) и от конкретного оборудования. Важно соблюдать порядок настройки и правильно указывать параметры подключения для успешной работы.

>>17749
В технической переписке на форуме специалистов недопустимо использовать не отредактированные ответы от нейронной сети по нескольким причинам:

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

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

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

Технические ошибки и лакуны: Нейронные сети могут не всегда следовать точным стандартам и правилам технической дисциплины. Например, могут быть допущены ошибки в коде, неправильные рекомендации по проектированию или некорректные математические выкладки.

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

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

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

Сап, анонч, работаю в неплохой айти конторе уже четвертый год как DevOps, фактически с самого основания, почти все люди с кем я начинал за это время уже поувольнялись, к тому же в этом году контору коноёбило - менялось руководство и организация, но на мне это никак не отражалось, разве что перевели в другое подразделение, зп с прошлого года не поднимали и она просела даже ниже рынка, но к слову и по работе я откровенно халявил т.к. за годы страх потерял, да и задачи то есть, то нихуя нет, не скажу что я хороший специалист, скорее наоборот, весьма хуёвый, типо значусь как мидл по выслуге лет и завершенным проектам, но по факту выше джуна+ себя не оценю, встречал нижестоящих ребят толковее, по бумажкам конечно профильное образование, общий опыт в айти уже больше 5 лет, рекомендации, со всеми «свой», «он там с самого начала» и из «старичков» один из немногих кто остался. Меня общая аморфность заебала ещё по осени и активно искал куда бы свалить, понимал что пора менять обстановку и воспалить очко для повышения эффекта, да и по зп хотелось повышения, но лень, полная удалёнка и болото общей стабильности не отпускало, особенно когда видел реальные требования к мидлам и отзывы из этих компаний про крысиные бега и переработки. Сейчас начался новый виток - подразделение в котором я числюсь сокращают, мне вроде похуй, когда позвонили «обрадовать» новостью подумал хороший вариант наконец сменить работу, там даже ахуели от моего спокойствия и позитива, вот только вчера мне выслали официальное уведомлении о сокращении в котором помимо всяких компенсаций мне выставили предложение вакантной должности на несколько порядков выше и с зарплатой больше чем в два раза чем у меня сейчас. Я сперва воспринял что это какой-то способ поглумиться, типо предложить должность на которую нельзя взять человека вроде меня что бы точно его пидорнуть под сокращение. А друзья сказали что это указывается гарантированная должность на которую в альтернативу сокращению готовы взять сотрудника. Да и на сайтах написано что по тк должны предложить вакансию соответствующую навыкам сотрудника либо ниже. А тут наоборот, указали сильно выше. Собственно вопрос: кто с таким сталкивался и что делать? Попробовать на похуй? Сказать типо да, я согласен?! А если я соглашусь и тресну из-за недостатка навыков? Или они этого и добиваются? Или они перед этим устроят какое-то собеседования после чего публично обоссут и выгонят с позором? Как вообще эта хуйня работает? Это фикция что бы формально предложить что-то сотруднику или реальная возможность остаться? Я же понимаю что такую должность и деньги мне никто в здравом уме не предложит, на неё в соседнем подразделении с трудом вхуячили маститого сеньора-помидора «из своих» с десятками лет в айти за спиной, а тут предлагают какому-то пиздрику (или они могут не знать что я пиздрик?). При этом есть инфа что остальным коллегам (кто в подразделении на других должностях и меньше года работает) нихуя не предложили, типо написали что вакансий свободных нет. А если я в открытую у кадровиков спрошу наёб ли это и зачем мне такое предложили? Они же поймут что я долбоёб и точно нахуй пошлют.
Просто никто из знакомых не сталкивался с сокращениями в вменяемых айтишных компаниях, есть только опыт друзей на заводах - там в такой ситуации предлагали какую-то нижестоящую хуйню типо уборщика-подсобника с зп в несколько раз ниже на которую никто не согласиться и свалит, либо же просто требовали уволиться под формальным поводом.

Ох бля. Вот и новый РАБочий год. 9 января я работал в конторе ровно год. Самому мне 24 годика, начал ишачить в 17 эникеем. Так что опыт работы, если убрать конторы, где я проработал мало и не накручивая опыт - 4 года. Оцениваю себя как мидл+. Собственно, обещали мне, что мб пойду потом дев опсом, но, как я и ожидал, получил нихуя. ЗП 180к в ДС. На НГ даже премию дали в качестве еще одной ЗП сверху. Планирую искать новую работу в июле, или если не заебет еще, то в след году. Собственно, есть 3 пути.
1. Метить в руководители, но не на нынешнем месте работы. Тут есть проблемы: у меня не все хорошо со софт скиллами (про них ниже), нету опыта руководства, ну и то, что по мне, надо отышачить на галере 3 года, чтобы понять структуру компании, как все работает и т.д
По софт скиллам. Расскажу одну не давнюю историю. Есть коллега, который чудковатый, но норм, против него ничего против не имею. Он сам админит на пол ставке где-то, но не суть. У нас было расширение офиса, так что я там только-только поставил коммутаторы и не до конца патч панель подключил. Т.к барен дал распоряжение быстро переехать в новую часть офиса, а им надо было подключить стенд, этот коллега решил сам полезть в шкаф и сделать так, что все заработало. И поебать ему было, в какой VLAN был скоммутирован порт. Я когда пришел, увидел, что он кинул через шкаф еще патч, я начал орать, хуле он творит. (Стенд вообще был подключен к юзерской сетки) В итоге перед ним извинился, ну и сказал, чтобы так больше не делал. Про 802.1X в курсе, эту идею забрил тех.дир
Следующая ситуация. Чел взял все оставшиеся сетевые фильтры со склада и отнес к СВОЕЙ КОМАНДЕ. Я к нему подошел, сказал, хуле он все запасы взял, ты не думай только о своей команде, о коллегах подумай. В это время это все подслушал один из баренов и написал тех.диру, что я ХУЕСОШУ КОЛЛЕГУ ТАК, ЧТО ОН НЕ ПОЗВОЛИЛ БЫ ГОВОРИТЬ СЕБЕ СО СВОИМИ ДЕТЬМИ. Мне это прилетает, на что я пишу, что это "наглый пиздеж" и полилось говно по трубам. Про то, что это барен другой был, я узнал потом. А мораль всей басни такова, что можно было ответить поумнее, но не додумался.
Алсо, была не давно оцен очка за год, по хард скиллам все збс, но все оценивают меня низко по софт скиллам. Из недовольств:
"Постоянно какой-то не доволен. Даже не хочется к нему подходить"
"Я пытаюсь с ним поговорить, а он в наушниках и не слышит меня"
"Иногда не здоровается"
"Не приветливый"
и т.п. Это я совсем еблан аутист? Или коллеги эти долбаебы? Никого нахуй не слал, конфликтов не было.
2. ДевОпсина. Что знаю из стека дев опса: gitlab-ci, Ansible, Docker, Grafana + Prom. Это что вспомнил. Опять же есть но. Я это знаю на начальном уровне. Сомневаюсь, что с такими знаниями меня возьмут на ЗП равной или большей. Сейчас жду билинк, буду кластер proxmox-а делать, а на нем на кубах сделать личный сайтик резюме, ну и подтягивать знания.
3. Идти в ВОТВАСЯТ, пердеть в кресло, повышать грейд, радоваться 13-й ЗП. Но с удаленкой.
Я хз короче, где-то я свернул не туда... Что делать? То что я тут последний год работаю - 95%. В ДевОпсы будет больно вкатываться по ЗП, софт скиллы не оч (я сам с этим соглашусь), а вакансии админов выше этой ЗП - это надо поискать. Рассудите, наставьте на путь.

>>31398
>>31398
1. Руковoдство

Плюсы:

— Перспективы роста в долгосрочной перспективе.
— Возможность сильно повысить ЗП, если всё удачно сложится.
— Шанс на развитие новых, ценных скиллов (управление, переговоры, мотивация).

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

Что делать: Если хочешь идти в руководители, начни работать над софт-скиллами прямо сейчас:
— Учи, как давать конструктивную обратную связь. Вместо «чего творишь», перефразируй: «Давай обсудим, как это лучше сделать в будущем, чтобы всё работало корректно».
— Работай над эмоциональным интеллектом. Это помогает справляться с конфликтами, даже когда ты прав.
— Тренируйся быть доброжелательно настойчивым: требуй своё, но без лишней агрессии.

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

2. ДевОпс

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

Минусы:
— Текущие знания — начального уровня, а вакансии ДевОпсов мидл+/сеньор уровня.
— Если будешь уходить в этой роли, возможен даунгрейд по ЗП на старте.
— Софт-скиллы для ДевОпсов тоже нужны (придётся общаться с разработчиками и командой).

Что делать:
— Продолжай развивать стек. Прокачай Ansible, CI/CD, Docker и Kubernetes до уверенного уровня.
— Кластер на Proxmox — хорошая идея, подтяни документацию, сделай упор на то, чтобы проект выглядел профессионально (как в резюме или на собесе).
— Параллельно начинай искать джун+/мидл вакансии ДевОпса, чтобы понять требования рынка.
— Сходи на несколько собеседований для проверки своей готовности и оценки себя на рынке.

3. Остаться админом

Плюсы:
— Стабильность. Уже понятно, как работать, ты в зоне комфорта.
— Если выйти на удаленку, можно без потерь продолжать развиваться.
— Постепенное повышение ЗП и грейда без кардинальных изменений.

Минусы:
— Меньше перспектив роста по сравнению с руководством или ДевОпс.
— Риски выгорания на текущей позиции.
— Чувство застоя, если хочется большего.

Что делать:
— Если останешься, всё равно нужно развивать софт-скиллы. Улучшение взаимодействия с коллегами даже на текущей позиции даст тебе больше возможностей.
— Попроси руководителей дать более интересные задачи, расширить обязанности (например, участие в автоматизации или проектах с прокачкой хард-скиллов).

Рекомендации

В краткосрочной перспективе (до июля):
Продолжай работать, подтягивай софт-скиллы и параллельно развивай стек ДевОпса. Кластер Proxmox + кубы — отличный проект для начала. Постепенно добавляй фичи и готовься к смене работы.

В среднесрочной перспективе:
Определи приоритет. Если хочешь стабильность — оставайся в админах и ищи варианты с удаленкой. Если хочешь роста — иди в ДевОпсы, даже если на старте придется потерять часть ЗП.

Софт-скиллы: Начни хотя бы с минимального:
— Приветствуй коллег. Даже если не хочется.
— Сними наушники, если кто-то пытается поговорить.
— Учись формулировать свои претензии без агрессии.

Успех в руководстве, да и в любой роли, требует эмоциональной зрелости. Это не значит «становись добрым и пушистым». Это значит: учи, как взаимодействовать с людьми, чтобы это приносило пользу тебе и им.
Ключевой совет

Дай себе время понять, что для тебя важно: стабильность или развитие. Админы с 180к в Москве — это хорошая позиция, но если у тебя есть амбиции, не бойся рискнуть. Главное — прокачай недостающие навыки и составь четкий план, как перейти в желаемую сферу.

репост из /hw/

итак, любители и пропагандисты ZFS, нужна ваша помощь.

oche/vazhny/bekap/270.zip
размер_файла_убрал_из-за_пидараса_попрошайки_на_которого_триггерится_спамлист 100% 42.93MB/s 0:02:42 (xfr#23937, ir-chk=64085/90987)
oche/vazhny/bekap/271.zip
размер_файла_убрал_из-за_пидараса_попрошайки_на_которого_триггерится_спамлист 100% 41.12MB/s 0:02:04 (xfr#23938, ir-chk=64084/90987)
oche/vazhny/bekap/272.zip
размер_файла_убрал_из-за_пидараса_попрошайки_на_которого_триггерится_спамлист 100% 41.26MB/s 0:02:57 (xfr#23939, ir-chk=64083/90987)
oche/vazhny/bekap/273.zip
размер_файла_убрал_из-за_пидараса_попрошайки_на_которого_триггерится_спамлист 100% 42.21MB/s 0:01:18 (xfr#23940, ir-chk=64082/90987)
oche/vazhny/bekap/274.zip
размер_файла_убрал_из-за_пидараса_попрошайки_на_которого_триггерится_спамлист 100% 42.84MB/s 0:02:03 (xfr#23941, ir-chk=64081/90987)
oche/vazhny/bekap/275.zip
размер_файла_убрал_из-за_пидараса_попрошайки_на_которого_триггерится_спамлист 100% 42.52MB/s 0:01:12 (xfr#23942, ir-chk=64080/90987)
oche/vazhny/bekap/276.zip
размер_файла_убрал_из-за_пидараса_попрошайки_на_которого_триггерится_спамлист 100% 41.38MB/s 0:01:17 (xfr#23943, ir-chk=64079/90987)
oche/vazhny/bekap/277.zip
размер_файла_убрал_из-за_пидараса_попрошайки_на_которого_триггерится_спамлист 35% 44.66MB/s 0:01:21

вопрос очевиден: какого хуя так медленно?!
запись на ZFS идёт со скростью 3000 мегабит в секунду, а чтение со скоростью 300 мегабит, какого хуя чтение в 10 раз медленнее, чем запись?!
восстановление из бэкапа идёт уже больше 24 часов!

> 07:28:04 up 1 day, 35 min, 3 users, load average: 0.64, 1.01, 0.96

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

проблема точно не в сетевухе, такая скорость и по 1гб меди, и по 10гб оптике. проблема точно не в сервере назначения, там относительно быстрые ссд.
на бэкап сервере массив Z1 (типа RAID5) из четырёх хдд, чтение идёт в 1 поток, никакой другой нагрузки на бэкап сервере нет, единственный процесс, который дрочит харды - rsync.
в какую сторону копать?

bkp /root# free -m
total used free shared buff/cache available
Mem: 64151 11987 51789 3 1091 52163
Swap: 0 0 0
bkp /root# arc_summary |grep cache
Most Frequently Used (MFU) cache size: 44.8 % 1.2 GiB
Most Recently Used (MRU) cache size: 55.2 % 1.4 GiB
Metadata cache size (hard limit): 75.0 % 23.5 GiB
Metadata cache size (current): 25.9 % 6.1 GiB
Dnode cache size (hard limit): 10.0 % 2.3 GiB
Dnode cache size (current): 83.7 % 2.0 GiB
L2 cached evictions: 0 Bytes
Cache hits by cache type:
spl_kmem_cache_kmem_threads 4
spl_kmem_cache_magazine_size 0
spl_kmem_cache_max_size 32
spl_kmem_cache_obj_per_slab 8
spl_kmem_cache_reclaim 0
spl_kmem_cache_slab_limit 16384
dbuf_cache_hiwater_pct 10
dbuf_cache_lowater_pct 10
dbuf_cache_max_bytes 18446744073709551615
dbuf_cache_shift 5
dbuf_metadata_cache_max_bytes 18446744073709551615
dbuf_metadata_cache_shift 6
spa_config_path /etc/zfs/zpool.cache
zfs_metaslab_max_size_cache_sec 3600
zfs_nocacheflush 0
zfs_vdev_cache_bshift 16
zfs_vdev_cache_max 16384
zfs_vdev_cache_size 0
zil_nocacheflush 0
VDEV cache disabled, skipping section

продолжаю держать в курсе.
тест последовательного чтения в один поток методом "dd status=progress bs=1M if=большойфайл of=/dev/null"
бэкап сервер с ZFS на ржавом железе

> 13607919882 bytes (14 GB, 13 GiB) copied, 99.7743 s, 136 MB/s

лайв сервер с EXT4 на ссд

> 73988571136 bytes (74 GB, 69 GiB) copied, 101 s, 733 MB/s

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

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

лайв сервер с mdadm RAID5 и SSD:

prod# sync; dd if=/dev/urandom of=test.bin bs=1M count=4096; time sync
4096+0 records in
4096+0 records out
4294967296 bytes (4.3 GB, 4.0 GiB) copied, 12.2952 s, 349 MB/s

real 0m4.846s
user 0m0.000s
sys 0m0.016s

prod# echo 3 > /proc/sys/vm/drop_caches; dd if=test.bin of=/dev/null bs=1M
4096+0 records in
4096+0 records out
4294967296 bytes (4.3 GB, 4.0 GiB) copied, 3.85484 s, 1.1 GB/s

= запись 3 гигабита, чтение 9 гигабит

бэкапник с ZFS RAID5 и HDD

backup# sync; dd if=/dev/urandom of=test.bin bs=1M count=4096; time sync
4096+0 records in
4096+0 records out
4294967296 bytes (4.3 GB, 4.0 GiB) copied, 11.1282 s, 386 MB/s

real 0m2.727s
user 0m0.000s
sys 0m0.042s

backup# echo 3 > /proc/sys/vm/drop_caches; dd if=test.bin of=/dev/null bs=1M
4096+0 records in
4096+0 records out
4294967296 bytes (4.3 GB, 4.0 GiB) copied, 32.6595 s, 132 MB/s

= запись 3+ гигабита, чтение 1 гигабит
тут почему-то чтение вышло в 3 раза быстрее, чем рсинкать на другой сервер.
может всё-таки какая-то хуйня между этими двумя серверами, позже попробую покидать туда-сюда данные между бэкапником и другим сервером.

между третьим сервером и лайв сервером с ссд туда-сюда честный гигабит по гигабитной меди, между третьим сервером и бэкапником с хдд-зфс всё те же 300 мегабит, но если положить тяжёлый файл в /dev/shm и качать оттуда, то будет так же честный гигабит, то есть проблема точно не в сети, а в зфс.

continuous read:

backup# sync; echo 3 > /proc/sys/vm/drop_caches; fio --ioengine=libaio --direct=1 --name=zfstest --filename=zfstest.bin --bs=1M --size=4G --readwrite=read --numjobs=1 --iodepth=1
zfstest: (g=0): rw=read, bs=(R) 1024KiB-1024KiB, (W) 1024KiB-1024KiB, (T) 1024KiB-1024KiB, ioengine=libaio, iodepth=1
fio-3.33
zfstest: (groupid=0, jobs=1): err= 0: pid=74269: Mon Jan 13 10:51:34 2025
iops : min= 44, max= 178, avg=119.49, stdev=31.98, samples=68
READ: bw=119MiB/s (125MB/s), 119MiB/s-119MiB/s (125MB/s-125MB/s), io=4096MiB (4295MB), run=34357-34357msec

random read:

backup# sync; echo 3 > /proc/sys/vm/drop_caches; fio --ioengine=libaio --direct=1 --name=zfstest --filename=zfstest.bin --bs=1M --size=4G --readwrite=randread --numjobs=1 --iodepth=1
zfstest: (g=0): rw=randread, bs=(R) 1024KiB-1024KiB, (W) 1024KiB-1024KiB, (T) 1024KiB-1024KiB, ioengine=libaio, iodepth=1
fio-3.33
zfstest: (groupid=0, jobs=1): err= 0: pid=79082: Mon Jan 13 10:54:00 2025
read: IOPS=65, BW=65.3MiB/s (68.5MB/s)(4096MiB/62723msec)
iops : min= 54, max= 88, avg=65.31, stdev= 3.66, samples=125
READ: bw=65.3MiB/s (68.5MB/s), 65.3MiB/s-65.3MiB/s (68.5MB/s-68.5MB/s), io=4096MiB (4295MB), run=62723-62723msec