Продолжаю развивать нужное приложение для трекинга прогресса в решении задач по математике и физике. Идея в том, чтобы не просто ставить галочку «сделано», а считать время сессий, ловить «инсайты» (моменты озарения) и получать за это очки.

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

Чтобы выбрать, какая нейронка будет крутиться под капотом, я написал бенчмарк и устроил прожарку популярным моделям через OpenRouter. В видео выше — подробный разбор полетов, а ниже — краткая выжимка результатов (спойлер: дорого — не всегда лучше).

Условия задачи

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

Задача моделей:

1. Распознать условие.

2. Понять ход решения.

3. Перевести всё это в красивый Markdown.

Аутсайдеры

Сразу отсеялись несколько кандидатов:

• OpenAPI GPT-5.1 CodexMax: Наделал кучу ошибок, не смог распознать корень 12-й степени из 128.

• Claude Haiku 4.5: Чуть лучше, но приняла мою рукописную единицу за семерку. И степень корня неправильно распозналась. В математике это фатально.

• Mistral Small 3.1: Вообще не поняла, что происходит на картинке. Забавно, что её "младшая" версия (Ministral 3B) справилась даже лучше - это мило, но все равно плохо.

Битва титанов и вопрос цены

В финал вышли модели от Google, и тут началось самое интересное — экономика.

Gemini 2.5 Pro Справилась хорошо. Распознала всё, включая разложение числа на степени двойки. Хотя и без особых пояснений (что могло косвенно следовать из промпта задания)

• Плюс: Высокая точность, понимает логику.

• Минус: Это «думающая» модель. Она долго обрабатывала запрос и сожрала 10 центов (~9-10 рублей) за одну фотку. Для частого использования в приложении — неоправданно дорого.

Gemini 3 Flash Preview А вот это — мой фаворит.

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

• Ум: Она не просто переписала текст, а объяснила, откуда взялся модуль числа (корень из квадрата) и почему при раскрытии модуля появился минус. Что я не стал расписывать т.к. это очевидно.

• Цена: И самое приятное — запрос стоил 0.4 цента (~40 копеек).

Итог

Разница в цене колоссальная: 10 рублей против 40 копеек при сопоставимом (а местами и лучшем) качестве. Flash Preview работает на "автомате" и ассоциациях, не уходя в глубокие раздумья, но для разбора рукописного текста этого оказалось достаточно.

Пока остановился на ней. Если у вас есть опыт с другими моделями для OCR рукописного текста (особенно формул) — делитесь в комментах, интересно потестить что-то еще.

Комплектация по обыкновению находится внутри корпуса. Для модели Formula V Line Crystal U2 ничего выдающегося: четыре стяжки, базовый набор винтов, креплений и латунных стоек, вместо инструкции — лист А4 с дублированием характеристик.

Внешний вид и дизайн

Formula V Line Crystal U2 — это стильный аквариумный корпус с закругленным передним стеклом и отдельным боковым стеклом младшего сегмента без встроенных вентиляторов и большим внутренним объёмом! Популярность подобных решений достигла своего пика, и мы видим, как каждый производитель стремится сделать актуальную модель подобного типа. И компания Formula V Line представила свой бюджетный вариант.

Конструкция Formula V Line Crystal U2 практически классическая — большая платформа с задним расположением блока питания и боковым правым отсеком для вентиляторов или СЖО типа 360 мм. Корпус Formula V Line Crystal U2 поставляется в белом и чёрном цветах, а также есть версия Crystal U2 Floe с четырьмя вентиляторами Floe 120BK/WH ARPW.

Главной изюминкой модели Formula V Line Crystal U2 является переднее закаленное стекло со скруглением. Толщина изделия составляет 4 мм. Оно фиксируется на два винта и около 7-8 зажимов, поэтому демонтировать его очень трудно, а главное — зачем? Боковое стекло толщиной поменьше, всего 3 мм.

Размеры корпуса 450 х 280 х 435 мм: я намерил 450 х 281 х 437 мм. Масса около 6 кг.

Formula V Line Crystal U2 поддерживает материнские платы форм-фактора ATX, microATX и mini-ITX, процессорные кулера высотой до 160 мм и видеокарты — до 410 мм (фактически даже до 440 мм).

Что очень важно и примечательно — это отсек сбоку для систем охлаждения. Он имеет глубину 50 мм, прибавим высоту латунных стоек 7 мм под материнскую плату, и значит, сюда можно установить классическую СЖО с толщиной радиатора 27-30 мм + вентиляторы 25 мм, и они не будут упираться в длинную видеокарту. Подобный изъян я ранее встречал на PowerCase Vision Micro M. Высота отсека равна ~405 мм.

А еще у данной модели большой объем внутреннего пространства, поэтому можно установить снизу, сбоку и сверху СЖО с радиаторами типоразмера 240-360 мм. Но есть и недостатки: всего 7 слотов расширения с одноразовыми заглушками. Да и производитель установить всего 6 стоек под материнскую плату, поэтому под ATX придется вручную еще докручивать три боковых.

В корпусе Formula V Line Crystal U2 очень много прорезей и места для кабель-менеджмента, но отсутствуют резиновые заглушки.

Суммарно модель Formula V Line Crystal U2 поддерживает до 10 вентиляторов формата 120 мм: три сверху, три сбоку, три снизу и один сзади. Также я насчитал три обычных фильтра на магнитной основе.

Я замерил толщину стали SPCC, и она составляет 0,6 мм вместе с краской. Сам производитель указывает на сайте 0,5 мм.

Передняя панель управления находится сверху справа. Здесь представлен классический набор из кнопок включения и перезагрузки, индикаторы активности, два аудиоразъема, по одному разъему USB 2.0, USB 3.0 и USB Type-C. Последний, к слову, базовой спецификации, то есть по скорости как USB 3.0.

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

Конструкция шасси

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

Забортовое пространство Formula V Line Crystal U2 типичное для панорамных корпусов. Отсеки разделены перегородкой.

Места для проводов в корпусе Formula V Line Crystal U2 достаточно: для блока питания и подключения периферии почти 10 см до платформы с материнской платой.

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

Корзина для жестких дисков Formula V Line Crystal U2 получила простое, но элегантное крепление на четырех замках и двух винтах крепления. Она вмещает до двух HDD 3,5″ и до двух SSD 2,5″. Можно ее и вовсе убрать, освободив пространство для кабеля питания процессора.

Провода для подключения корпуса Formula V Line Crystal U2 наделены базовым набором: четыре для портов передней панели к материнской плате, по одному USB 2.0 и Audio, спаренный коннектор USB 3.0 для Type-C и USB 3.0.

Заключение

Formula V Line Crystal U2 — это бюджетный аквариумный корпус с панорамным видом и закругленным стеклом. Он оказался достаточно вместительным и объемным для установки крупных комплектующих. Его сильными сторонами являются стоимость, дизайн и возможность установки вентиляторов до 10 штук. Мне также понравилась простота и удобство, отсутствие лишних изысков в угоду доступности по цене.

Однако у модели Formula V Line Crystal U2 имеются и свои недостатки — это одноразовые заглушки слотов расширения. Такие особенности, как отсутствие вентиляторов, я не считаю минусом, потому что конкретно данная версия так себя и позиционирует, открывая возможность пользователю самому купить желаемые вертушки. В сбалансированном представлении можно установить СЖО 360 мм сбоку на вдув и три вентилятора сверху на выдув.

Подводя итоги, корпус Formula V Line Crystal U2 является простым, но добротным корпусом стоимостью 5000-5500 рублей с закругленным стеклом и общей концепцией. Можно поискать за эти деньги версию Floe с четырьмя вентиляторами, благо она иногда всплывает на маркетплейсах. Поискав аналоги, то они идут немного дороже, а версии от Jonsbo стоят нередко в два раза больше.

Внешний вид и дизайн

Твердотельный накопитель Silicon Power XS90 является одним из самых быстрых в линейке компании на интерфейсе PCIe 5.0 x4 с поддержкой NVMe 2.0 и скоростью чтения до 14300 МБ/с и записи до 13400 МБ/с. Однако, что меня удивило, вместе с устройством отсутствует какой-либо массивный радиатор, ведь данные SSD славятся своим горячим нравом. Наверное, разработчики исходили из того факта, что подобное решение покупается к материнской плате верхнего и топового уровня, а у них собственное охлаждение M.2 значительно эффективнее. Поэтому на модели Silicon Power XS90 присутствует только декоративная металлизированная наклейка.

Согласно информации, Silicon Power XS90 производится с применением контроллера Silicon Motion SM2508, выпускающегося по 6-нанометровому техпроцессу TSMC. В ассортименте производителя есть версии на 1, 2 И 4 Тбайт. А вот данных о ресурсе записи (TBW) на сайте мне найти не удалось.

Модель Silicon Power XS90 построена на двухсторонней печатной плате, где с одной стороны находятся контроллер, DRAM-буфер и два чипа NAND, с другой — дополнительно два чипа NAND.

Сердцем твердотельного накопителя Silicon Power XS90 является ранее названный контроллер Silicon Motion SM2508, изготовленный в конце 2025 года. Согласно открытым источникам, его одно из преимуществ — энергоэффективность: потребление примерно составляет 9W против 13-14W у аналогов. Правее находится чип DRAM-буфера от Micron стандарта LPDDR4, но вот снова я не нашел точных характеристик (поиск по маркировке не выдал результатов).

Утилита от Вадима Очкина определила основную информацию об устройств. В качестве флэш-памяти используются четыре микросхемы производства Micron. В каждом чипе заключено 232-слойных 1024-Гбит кристаллов TLC 3D NAND (B58R).

Описание тестового стенда

Основное тестирование проводилось на домашнем тестовом стенде, включающем процессор Intel Core i5-14600KF и материнскую плату MSI MPG Z790 Tomahawk MAX WiFi.

Silicon Power XS90 охлаждался штатной пластиной MS Frozr SSD.

Тестирование

После подключения и инициализации накопителя Silicon Power XS90 общий доступный объем составляет 1,81 Тбайт.

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

Дополнительная вкладка с информацией из программы HWINFO64.

В первом бенчмарке CrystalDiskMark твердотельный накопитель Silicon Power XS90 практически демонстрирует заявленные скорости ~14275/13070 МБ/с с разным объемом данных.

Копирование с основного диска PCIe 4.0 x4 на Silicon Power XS90 происходит при скорости ~3,8-4,1 ГБ/с, я перепроверял несколько раз.

Далее следует линейная запись AIDA64 на весь объем. Первые 18% накопитель отрабатывает при скорости почти 10 ГБ/с, далее происходит падение до 2,5 ГБ/с. «Пила» в конце означает, что контроллер параллельно и записывал данные, и пытался очистить кеш.

Продолжим линейным чтением AIDA64. Среднее значение варьируется от 9600 МБ/с до 10600 МБ/с.

Основные показатели скорости при тестировании утилитoй ATTO Disk Benchmark. Общее значение 13,31 ГБ/с и 12,03 ГБ/с в пиковых значениях.

Обратимся к другой утилите для тестов AS SSD Benchmаrk.

На весь объем отмечаем среднее чтение 10 ГБ/сек и среднюю запись 10,2 ГБ/с.

Температурный режим

Первоначально я тестировал Silicon Power XS90 на нагрев под радиатором материнской платы тремя прогонами программы ATTO Disk Benchmark, которая создает высокую нагрузку.

Максимальная температура по встроенным датчикам Silicon Power XS90 составила до 56°С и 75°С, что я могу назвать отличным результатом! Тепловизор рассмотрел лишь 46°С.

Однако куда интереснее проверить Silicon Power XS90 на нагрев без охлаждения, оценить риски и момент троттлинга для защиты от перегрева. Не повторяйте такое дома.

По датчикам нагрев Silicon Power XS90 достиг 89°С, что является очень высоким, но не критическим значением: многие другие SSD PCIe 5.0 x4 достигают 105°С! Поэтому энергоэффективность данного контроллера действительно хороша. Тепловизор отметил самой горячей точкой микросхему Silicon Motion со значением крышки 78°С.

У меня остались оригиналы скриншотов, и могу сказать, что троттлинга Silicon Power XS90 при 89°С не было!

Заключение

Твердотельный накопитель Silicon Power XS90 оставляет о себе приятные впечатления. Это высокопроизводительный SSD формата M.2 2280 с умеренным тепловыделением, подойдет для любых сборок, включая игровые приставки или компактные мини-ПК, а благодаря его высоким скоростным показателям до 14300/13400 МБ/с позволяет использовать в современных мощных геймерских ПК.

Мне понравился накопитель Silicon Power XS90 также и благодаря своим общим впечатлениям: несмотря на бум стоимости, среди аналогов данная модель является одной из самых демократичных, нет переплаты за лишний радиатор. Но мне не нравится, что отсутствует информация о ресурсе устройства (TWB).

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

Предисловие

В условиях растущих требований к обработке больших данных и аналитическим нагрузкам (OLAP) критически важной становится не только настройка самой СУБД, но и тонкая оптимизация операционной системы, на которой она работает. Однако в современных исследованиях и практических руководствах наблюдается значительный пробел: рекомендации по настройке PostgreSQL часто ограничиваются параметрами самой СУБД, в то время как влияние параметров ядра Linux на производительность базы данных остаётся малоизученной областью.

Данная работа направлена на заполнение этого пробела. Фокус исследования сосредоточен на влиянии параметра ядра Linux vm.vfs_cache_pressure на производительность PostgreSQL под синтетической OLAP-нагрузкой. Этот параметр контролирует агрессивность, с которой ядро освобождает кэш файловой системы (VFS cache), что в теории может напрямую влиять на поведение СУБД, активно работающей с файлами данных.

Исследование носит экспериментальный характер и построено на методологии нагрузочного тестирования с использованием специализированного инструмента pg_expecto. В качестве тестовой среды используется конфигурация, типичная для небольших аналитических серверов: 8 CPU, 8 GB RAM, дисковая подсистема, подверженная ограничениям пропускной способности. Это позволяет смоделировать условия, в которых грамотная настройка ОС может стать ключом к раскрытию дополнительной производительности или, наоборот, источником проблем.

Ценность данной работы заключается в её практической ориентированности. Она предоставляет администраторам баз данных и системным инженерам не только конкретные данные о влиянии настройки, но и методологию анализа комплексного поведения системы (СУБД + ОС) под нагрузкой, выходящую за рамки простого мониторинга TPS (транзакций в секунду).

Предпосылка к исследованию

Отсутствие специализированных исследований: Поиск в научных базах данных (Google Scholar, IEEE Xplore) и технических блогах по запросам "vfs_cache_pressure PostgreSQL performance", "Linux kernel tuning for database workload" не выявил работ, фокусирующихся на экспериментальном изучении данного конкретного взаимодействия. Основная масса материалов предлагает общие советы или рассматривает настройку памяти PostgreSQL в отрыве от тонких параметров ОС.

Задача

Оценить влияние изменения параметра vm.vfs_cache_pressure на производительность СУБД и инфраструктуры при синтетической нагрузке, имитирующей OLAP.

Параметры инфраструктуры

vm.dirty_expire_centisecs=3000

vm.dirty_ratio=30

vm.dirty_background_ratio=10

vm.swappiness=10

read_ahead_kb=4096

Параметры СУБД

shared_buffers = '4GB'

effective_cache_size = '6GB'

work_mem = '32MB'

Нагрузка на СУБД в ходе экспериментов

Отношение прочитанных блоков shared_buffers к измененным блокам shared_buffers (OLAP):

• vm.vfs_cache_pressure = 100 : 177.98

• vm.vfs_cache_pressure = 50 : 184.26

• vm.vfs_cache_pressure = 150 : 172.22

Часть 1 - Общая постановка исследования и результаты производительности СУБД и инфраструктуры.

Корреляционный анализ ожиданий СУБД

Операционная скорость

Медианные значения операционной скорости:

• vm.vfs_cache_pressure = 100 : 15 154 (baseline)

• vm.vfs_cache_pressure = 50 : 16 185 (-11.27%)

• vm.vfs_cache_pressure = 150 : 15 095 (+8.65%)

Ожидания типа IO

Медианные значения ожиданий типа IO:

• vm.vfs_cache_pressure = 100 : 16 716 (baseline)

• vm.vfs_cache_pressure = 50 : 19 411 (+16,12%)

• vm.vfs_cache_pressure = 150 : 16 762 (+0,27%)

Ожидания типа LWLock

Медианные значения ожиданий типа LWLock:

• vm.vfs_cache_pressure = 100 : 178(baseline)

• vm.vfs_cache_pressure = 50 : 113 (-36,52%)

• vm.vfs_cache_pressure = 150 : 167 (-6,46%)

Производительность подсистемы IO (IOPS) файловой системы /data

Медианные значения IOPS:

• vm.vfs_cache_pressure = 100 : 3 502(baseline)

• vm.vfs_cache_pressure = 50 : 3 479(-0,66%)

• vm.vfs_cache_pressure = 150 : 3 582 (+2,28%)

Пропускная способность подсистемы IO (MB/s) файловой системы /data

Медианные значения MB/s:

• vm.vfs_cache_pressure = 100 : 125(baseline)

• vm.vfs_cache_pressure = 50 : 103(-17,60%)

• vm.vfs_cache_pressure = 150 : 135 (+8,00%)

Часть 2 - Анализ паттернов производительности инфраструктуры

Входные данные для анализа

Сводный отчета по нагрузочному тестированию подготовленный pg_pexpecto по окончании нагрузочного тестирования:

• Метрики производительности и ожиданий СУБД

• Метрики vmstat

• Метрики iostat

• Корреляционный анализ ожиданий СУБД

• Корреляционный анализ метрик vmstat

• Корреляционный анализ метрик iostat

Общий анализ инфраструктуры при разном значении vm.vfs_cache_pressure

1. Влияние на IO-ожидания (wa)

Общая проблема: Во всех трёх экспериментах 100% наблюдений показывают wa > 10%, что свидетельствует о системном ограничении дисковой подсистемы.

Сравнение корреляций при разных значениях vm.vfs_cache_pressure:

vm.vfs_cache_pressure=50:

• Корреляция IO-wa: -0,0772 (отсутствует/отрицательная) ✅

• Корреляция IO-b: 0,0609 (слабая/средняя) ℹ️

• Корреляция IO-bi: 0,3650 (слабая/средняя) ℹ️

• Корреляция IO-bo: 0,2693 (слабая/средняя) ℹ️

vm.vfs_cache_pressure=100:

• Корреляция IO-wa: -0,9020 (отсутствует/отрицательная) ✅

• Корреляция IO-b: 0,2611 (слабая/средняя) ℹ️

• Корреляция IO-bi: 0,2730 (слабая/средняя) ℹ️

• Корреляция IO-bo: 0,6533 (высокая) ⚠️

vm.vfs_cache_pressure=150:

• Корреляция IO-wa: -0,7379 (отсутствует/отрицательная) ✅

• Корреляция IO-b: 0,0000 (отсутствует/отрицательная) ✅

• Корреляция IO-bi: 0,5074 (высокая) ⚠️

• Корреляция IO-bo: 0,5532 (высокая) ⚠️

Вывод: Увеличение vfs_cache_pressure усиливает корреляцию IO-ожиданий с операциями чтения/записи (bi/bo), что указывает на более агрессивное управление кэшем файловой системы.

2. Паттерны использования процессов в состоянии D (непрерываемый сон)

Наблюдаемый феномен:

· При vfs_cache_pressure=50: ALARM по регрессионной линии (R²=0,7, угол наклона 39,83)

· При vfs_cache_pressure=100: R²=0,03, угол наклона 10,38 (норма)

· При vfs_cache_pressure=150: R²=0,00, угол наклона 0,00 (норма)

Объяснение с точки зрения управления кэшем:

• При низком значении vfs_cache_pressure(50) ядро менее агрессивно вытесняет кэш файловой системы

• Это приводит к накоплению большего объёма кэшированных данных

При OLAP-нагрузке с интенсивным чтением это вызывает:

• Более частые блокировки процессов в состоянии D при обращении к диску

• Увеличение времени ожидания из-за конкуренции за IO-ресурсы

При значениях 100 и 150 кэш вытесняется активнее, что снижает конкуренцию и количество процессов в состоянии D

3. Производительность дисковой подсистемы и кэширования

Общие характеристики нагрузки (все эксперименты):

• Соотношение чтения к записи: ~180:1 (типичный OLAP-паттерн)

• Очень высокая корреляция скорости операций с чтением (0,85-0,88)

• Очень высокая корреляция скорости операций с записью (0,98-0,99)

• Система ограничена производительностью диска

Влияние pressure на эффективность shared buffers:

• HIT RATIO shared buffers: 55-58% (критически низкий во всех случаях)

• Корреляция shared_blks_hit - shared_blks_read: 0,96-0,97 (очень высокая)

• Вывод: vfs_cache_pressure практически не влияет на HIT RATIO PostgreSQL, так как shared buffers управляются отдельно от кэша файловой системы

Ключевые выводы по экспериментам

Лучшие показатели у pressure=100:

• Отсутствие роста процессов в состоянии D

• Умеренные корреляции с операциями чтения/записи

• Стабильное поведение системы

Проблемные зоны (все эксперименты):

• Критически низкий HIT RATIO shared buffers (55-58%)

• 100% наблюдений с wa > 10%

• Система ограничена производительностью диска

Рекомендации по оптимизации для OLAP-нагрузки

1. Настройки операционной системы:

Установить vm.vfs_cache_pressure = 100 (компромиссное значение)

Пересмотреть настройки vm.dirty_*:

• Уменьшить vm.dirty_background_ratio с 10 до 5

• Уменьшить vm.dirty_ratio с 30 до 20

• Это снизит латентность записи

Проверить и оптимизировать параметры файловой системы

2. Настройки PostgreSQL для OLAP:

• Увеличить shared_buffers с 4GB до 6GB (при 8GB RAM)

• Увеличить work_mem с 32MB до 128-256MB для сложных сортировок

• Увеличить effective_cache_size до 6-7GB

• Рассмотреть увеличение max_parallel_workers_per_gather с 1 до 2-4

• Установить random_page_cost = 1.0 (если используются SSD)

3. Аппаратные улучшения:

• Рассмотреть переход на более быстрые диски (NVMe SSD)

• Увеличить объём оперативной памяти с 8GB

• Проверить балансировку нагрузки между дисками данных и WAL

Анализ влияния vfs_cache_pressure на управление RAM

1. Использование оперативной памяти

Общая ситуация:

• Во всех экспериментах свободная RAM < 5% в более 50% наблюдений - это норма для сервера с активной нагрузкой

• Оперативная память практически полностью используется (7-7.2GB из 8GB)

Динамика memory_swpd (использование свопа):

• vfs_cache_pressure=50: Рост с 209 MB до 347 MB (+138 MB за 110 минут)

• vfs_cache_pressure=100: Рост с 260 MB до 328 MB (+68 MB за 111 минут)

• vfs_cache_pressure=150: Рост с 246 MB до 338 MB (+92 MB за 110 минут)

Анализ скорости роста:

• Наиболее медленный рост swpd при vfs_cache_pressure=100 (68 MB за период)

• Наиболее быстрый рост при vfs_cache_pressure=50 (138 MB за период)

• Промежуточный рост при vfs_cache_pressure=150 (92 MB за период)

Стабильность использования памяти:

Наиболее стабильное поведение при vfs_cache_pressure=100:

• Наименьший рост использования свопа

• Плавное изменение memory_swpd без резких скачков

• Более предсказуемое управление памятью

Наименее стабильное поведение при vfs_cache_pressure=50:

• Быстрый рост использования свопа

• Более агрессивное вытеснение данных в своп

2. Свопинг (swap in/out)

Статистика по экспериментам:

vfs_cache_pressure=50:

• swap in: 10% наблюдений

• swap out: 6.36% наблюдений

• Баланс смещен в сторону чтения из свопа

При vfs_cache_pressure=100:

• swap in: 9.01% наблюдений

• swap out: 1.80% наблюдений

• Минимальный объем записи в своп

vfs_cache_pressure=150:

• swap in: 10% наблюдений

• swap out: 11.82% наблюдений

• Наибольший объем записи в своп

Объяснение различий:

1. vfs_cache_pressure=50:

• Низкое давление на кэш файловой системы

• Ядро менее агрессивно освобождает кэш

• Чаще приходится читать из свопа (высокий swap in)

• Относительно низкий swap out - меньше данных вытесняется

2. vfs_cache_pressure=100:

• Оптимальный баланс

• Кэш управляется эффективно

• Минимальный swap out - редко требуется запись в своп

• Умеренный swap in - меньше обращений к свопу

3. vfs_cache_pressure=150:

• Высокое давление на кэш файловой системы

• Ядро агрессивно освобождает кэш

• Высокий swap out - активная запись в своп

• Высокий swap in - частые чтения из свопа

3. Кэширование и dirty pages

Взаимодействие vfs_cache_pressure с настройками vm.dirty_*:

Текущие настройки:

• vm.dirty_ratio=30 (запись блокируется при 30% dirty pages)

• vm.dirty_background_ratio=10 (фоновая запись при 10%)

• read_ahead_kb=4096 (4MB read-ahead)

Влияние pressure на dirty pages:

1. vfs_cache_pressure=50:

• Медленное освобождение кэша

• Больше данных остается в памяти

• Более высокий риск достижения dirty_ratio

• Потенциальные блокировки записи при всплесках нагрузки

2. vfs_cache_pressure=100:

• Сбалансированное управление

• Кэш освобождается своевременно

• Меньше риск блокировок из-за dirty pages

• Оптимально для текущих настроек dirty_*

3. vfs_cache_pressure=150:

• Быстрое освобождение кэша

• Меньше данных в кэше файловой системы

• Чаще требуется чтение с диска

• Возможна излишняя агрессивность для OLAP

Оптимальные значения для OLAP-нагрузки:

Для OLAP с большим чтением рекомендуется:

• vfs_cache_pressure=100-120 (компромиссное значение)

• read_ahead_kb=8192-16384 (увеличение для последовательного чтения)

• vm.dirty_background_ratio=5 (более частая фоновая запись)

• vm.dirty_ratio=20 (раньше начинать синхронную запись)

Обоснование:

• OLAP характеризуется последовательным чтением больших объемов данных

• Большой read-ahead улучшает производительность последовательного чтения

• Более низкие dirty_* значения снижают латентность записи

• vfs_cache_pressure=100 обеспечивает баланс между кэшированием и доступной памятью

Анализ влияния vfs_cache_pressure на CPU

1. Нагрузка на CPU

Ключевые наблюдения:

• Все эксперименты показывают очень высокую корреляцию LWLock с user time (0.96-0.98)

• Все эксперименты показывают очень высокую корреляцию LWLock с system time (0.91-0.95)

Распределение CPU времени по экспериментам:

vfs_cache_pressure=50:

• us (user time): 21-61% (среднее ~30%)

• sy (system time): 5-10% (среднее ~7%)

• wa (I/O wait): 17-31% (среднее ~27%)

• id (idle): 12-42% (среднее ~35%)

vfs_cache_pressure=100:

• us (user time): 25-57% (среднее ~35%)

• sy (system time): 5-10% (среднее ~7%)

• wa (I/O wait): 18-29% (среднее ~25%)

• id (idle): 14-41% (среднее ~33%)

vfs_cache_pressure=150:

• us (user time): 22-58% (среднее ~32%)

• sy (system time): 5-10% (среднее ~7%)

• wa (I/O wait): 16-28% (среднее ~24%)

• id (idle): 13-41% (среднее ~34%)

Влияние vfs_cache_pressure:

• User time: Наиболее высокий при pressure=100 (среднее 35%)

• System time: Практически идентичен во всех случаях (~7%)

• I/O wait: Наименьший при pressure=150 (среднее 24%)

• Idle time: Наибольший при pressure=50 (среднее 35%)

Вывод: Увеличение pressure снижает I/O wait, но незначительно увеличивает user time, что указывает на более активную обработку данных приложением.

2. Переключения контекста

Общая картина:

• Высокая корреляция переключений контекста с прерываниями (cs-in) во всех экспериментах (0.95-0.97)

• При vfs_cache_pressure=150 появляется слабая/средняя корреляция cs-sy (0.0244)

Влияние управления кэшем на переключения контекста:

Механизм влияния:

1. vfs_cache_pressure=50:

• Менее агрессивное управление кэшем

• Меньше системных вызовов для управления памятью

• Переключения контекста в основном вызваны прерываниями от дисковых операций

2. vfs_cache_pressure=100:

• Сбалансированное управление кэшем

• Умеренное количество системных вызовов для управления памятью

• Прерывания остаются основной причиной переключений контекста

3. vfs_cache_pressure=150:

• Агрессивное управление кэшем

• Увеличение системных вызовов для управления памятью

• Появление корреляции cs-sy указывает на рост времени ядра на управление памятью

Объяснение корреляции cs-sy при pressure=150:

Ядро тратит больше времени на:

• Вытеснение страниц из кэша файловой системы

• Управление списками страниц памяти

• Обработку запросов на выделение/освобождение памяти

• Это приводит к увеличению system time и связанных с ним переключений контекста

3. Очередь выполнения (run queue)

Статистика по экспериментам:

vfs_cache_pressure=50:

• Проценты превышения ядер CPU: 7.27%

• Максимальное значение procs_r: 10 процессов

• Более стабильная очередь выполнения

vfs_cache_pressure=100:

• Проценты превышения ядер CPU: 16.22%

• Максимальное значение procs_r: 11 процессов

• Наименее стабильная очередь выполнения

vfs_cache_pressure=150:

• Проценты превышения ядер CPU: 14.55%

• Максимальное значение procs_r: 11 процессов

• Промежуточная стабильность

Анализ стабильности:

Наиболее стабильная очередь при pressure=50:

• Наименьший процент превышения ядер CPU (7.27%)

• Более равномерное распределение нагрузки

• Меньше конкуренции за CPU ресурсы

Наименее стабильная очередь при pressure=100:

• Наибольший процент превышения ядер CPU (16.22%)

• Более выраженная конкуренция за CPU

• Возможные задержки в обработке запросов

Рекомендации по балансировке vfs_cache_pressure

Для конфигурации: 8 CPU ядер, 8GB RAM, OLAP-нагрузка с интенсивным чтением

1. Оптимальный диапазон значений: vfs_cache_pressure = 90-110

Обоснование:

Компромисс между производительностью и стабильностью:

• vfs_cache_pressure=50: лучшая стабильность очереди выполнения, но выше I/O wait

• vfs_cache_pressure=150: ниже I/O wait, но выше нагрузка на ядро (system time)

• vfs_cache_pressure=100: баланс между этими крайностями

2. Сопутствующие настройки для OLAP-нагрузки:

Настройки операционной системы:

• vm.swappiness = 10 (уже установлено, оптимально для серверов)

• vm.dirty_background_ratio = 5 (уменьшить с 10 для более частой фоновой записи)

• vm.dirty_ratio = 20 (уменьшить с 30 для снижения латентности записи)

• read_ahead_kb = 16384 (увеличить для последовательного чтения OLAP)

Настройки PostgreSQL для 8 CPU ядер:

• max_parallel_workers_per_gather = 2-4 (увеличить с 1 для OLAP)

• max_worker_processes = 16 (уже установлено, оптимально)

• max_parallel_workers = 16 (уже установлено, оптимально)

• work_mem = 64-128MB (увеличить с 32MB для сложных сортировок)

Часть 3 - Анализ производительности подсистемы IO для файловой системы /data

Задача

Проанализировать параметра vm.vfs_cache_pressure на производительность подсистемы IO для дискового устройства, используемого файловой системой /data.

Входные данные для анализа

Сводный отчета по нагрузочному тестированию подготовленный pg_pexpecto по окончании нагрузочного тестирования:

• Метрики iostat для дискового устройства vdd

Анализ корреляций и типа нагрузки

vm.vfs_cache_pressure = 100

• Корреляция скорость–IOPS: слабая (0,4128).

• Корреляция скорость–MB/s: очень высокая (0,8191).

• Тип нагрузки: аналитическая/ETL, так как наблюдается высокая зависимость от пропускной способности диска, а не от IOPS.

Ограничивающий фактор: пропускная способность диска (MB/s).

Дополнительные наблюдения:

• Утилизация диска стабильно высокая (89–94%).

• Задержки чтения/записи умеренные (9–14 мс).

• Нагрузка на CPU в режиме ожидания I/O (wa) составляет 18–29%.

vm.vfs_cache_pressure = 50

• Корреляция скорость–IOPS: отрицательная (-0,2879).

• Корреляция скорость–MB/s: очень высокая (0,8017).

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

Ограничивающий фактор: пропускная способность диска (MB/s).

Дополнительные наблюдения:

• Утилизация диска близка к максимальной (95–96%).

• Задержки чтения растут со временем (до 16 мс).

• Отрицательная корреляция с IOPS указывает на возможные проблемы с CPU, блокировками или памятью.

• Нагрузка на CPU в режиме ожидания I/O (wa) достигает 31%.

vm.vfs_cache_pressure = 150

• Корреляция скорость–IOPS: слабая (0,5930).

• Корреляция скорость–MB/s: очень высокая (0,9735).

• Тип нагрузки: аналитическая/ETL с сильной зависимостью от пропускной способности диска.

Ограничивающий фактор: пропускная способность диска (MB/s).

Дополнительные наблюдения:

• Утилизация диска стабильно высокая (89–95%).

• Задержки чтения/записи низкие (6–11 мс).

• Нагрузка на CPU в режиме ожидания I/O (wa) снижается к концу теста (до 16%).

Сводные выводы

1. Все три эксперимента показывают схожую картину:

• Производительность ограничена пропускной способностью диска (MB/s), а не IOPS.

• Нагрузка носит аналитический/ETL-характер (последовательное чтение/запись больших объёмов данных).

2. Влияние vm.vfs_cache_pressure:

• Изменение параметра не оказало значительного влияния на тип нагрузки и ограничивающий фактор.

• Наилучшие показатели задержек и утилизации CPU наблюдаются при значении 150.

3. Рекомендации:

• Увеличить пропускную способность дисковой подсистемы .

• Настроить параметры PostgreSQL для аналитических нагрузок (work_mem, maintenance_work_mem, effective_io_concurrency).

• Рассмотреть использование партиционирования таблиц и параллельного выполнения запросов.

Сравнение метрик диска

Средние значения метрик по экспериментам:

vm.vfs_cache_pressure = 50:

• utilization: 95,1%

• r_await: 13,8 мс

• w_await: 6,6 мс

• IOPS: 3 490

• MB/s: 116,1

• aqu_sz: 43,8

• cpu_wa: 27,3%

vm.vfs_cache_pressure = 100:

• utilization: 92,7%

• r_await: 12,5 мс

• w_await: 7,0 мс

• IOPS: 3 513

• MB/s: 129,6

• aqu_sz: 40,5

• cpu_wa: 25,4%

vm.vfs_cache_pressure = 150:

• utilization: 92,7%

• r_await: 9,8 мс

• w_await: 7,3 мс

• IOPS: 3 570

• MB/s: 137,5

• aqu_sz: 33,5

• cpu_wa: 23,6%

Анализ влияния vfs_cache_pressure:

1. Задержки и утилизация диска:
   r_await последовательно снижается с ростом параметра: 13,8 мс (50) → 12,5 мс (100) → 9,8 мс (150)
   w_await незначительно увеличивается: 6,6 мс (50) → 7,0 мс (100) → 7,3 мс (150)
   Утилизация диска максимальна при значении 50 (95,1%), при 100 и 150 стабилизируется на уровне 92,7%
   Наилучшие показатели задержек чтения достигаются при максимальном значении 150

2. Связь с пропускной способностью и IOPS:
   Пропускная способность (MB/s) монотонно растёт: 116,1 (50) → 129,6 (100) → 137,5 (150)
   IOPS также увеличивается: 3 490 (50) → 3 513 (100) → 3 570 (150)
   Наблюдается чёткая тенденция: чем выше vfs_cache_pressure, тем выше производительность по пропускной способности

3. Поведение очереди запросов (aqu_sz):
   Длина очереди последовательно уменьшается: 43,8 (50) → 40,5 (100) → 33,5 (150)
   Это свидетельствует о более эффективной обработке запросов при высоких значениях параметра
   Уменьшение очереди коррелирует со снижением времени ожидания CPU (cpu_wa)

Ключевые выводы:

Увеличение vfs_cache_pressure до 150 даёт наиболее сбалансированные результаты:

• Наименьшие задержки чтения (9,8 мс против 13,8 мс при 50)

• Наибольшая пропускная способность (137,5 MB/s против 116,1 при 50)

• Самая короткая очередь запросов (33,5 против 43,8 при 50)

• Наименьшая нагрузка на CPU в режиме ожидания (23,6% против 27,3% при 50)

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

• Более высокие значения способствуют более агрессивному освобождению кэша

• Это снижает contention за память и уменьшает задержки

• Однако может незначительно увеличить задержки записи

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

Итог исследования

Проведённое комплексное исследование убедительно демонстрирует, что параметр ядра Linux vm.vfs_cache_pressure оказывает статистически значимое и многогранное влияние на производительность PostgreSQL при OLAP-нагрузке, имитирующей последовательное чтение больших объёмов данных.

Ключевые обобщённые выводы:

1. Тип нагрузки является определяющим: Во всех экспериментах система упиралась в пропускную способность диска (MB/s), а не в IOPS, что характерно для аналитических (OLAP) паттернов с последовательным доступом. Это главный ограничивающий фактор в данной конфигурации.

2. Влияние на кэширование и память:

   Параметр практически не влияет на hit ratio внутреннего кэша PostgreSQL (shared buffers), что подтверждает их независимое управление.

   Однако он существенно влияет на управление кэшем файловой системы (VFS cache) и подкачкой (swap). Более низкие значения (50) приводят к меньшей агрессивности вытеснения кэша, что вызывает более быстрый рост использования свопа и большее количество процессов, блокированных в состоянии ожидания ввода-вывода (D-состояние). Более высокие значения (150) заставляют ядро активнее освобождать кэш.

3. Влияние на производительность диска: Наблюдается чёткая тенденция: с ростом vfs_cache_pressure увеличивается пропускная способность (MB/s) и снижаются задержки чтения (r_await). Наилучшие показатели дисковых операций были достигнуты при значении 150.

4. Влияние на загрузку CPU и стабильность: Значение параметра также влияет на баланс загрузки процессора. Более высокие значения снижают время ожидания ввода-вывода (wa), но могут незначительно повысить системное время (sy) из-за активного управления памятью и привести к менее стабильной очереди выполнения процессов (run queue).

5. Недостатки тестовой конфигурации: Исследование выявило системные проблемы, общие для всех тестов:

   • Критически низкий hit ratio shared buffers (55-58%), указывающий на недостаточный объём оперативной памяти для данной рабочей нагрузки.

   • Постоянно высокий уровень ожидания ввода-вывода (wa > 10%), подтверждающий, что диск является узким местом.

Общие рекомендации для OLAP-нагрузок на PostgreSQL:

• Аппаратные улучшения (более быстрые NVMe SSD, увеличение RAM) имеют высший приоритет для снятия выявленных ограничений.

• Оптимизация ОС: Уменьшение vm.dirty_* соотношений для снижения латентности записи и увеличение read_ahead_kb для ускорения последовательного чтения.

• Оптимизация PostgreSQL: Увеличение shared_buffers, work_mem, effective_cache_size и настройка параметров параллельного выполнения.

Анализ расхождений в рекомендациях: vm.vfs_cache_pressure = 100 vs 150

В исследовании содержится кажущееся противоречие: в Части 2 оптимальным названо значение 100, а в Части 3 — 150. Причина этих разных рекомендаций заключается не в ошибке, а в разном фокусе анализа и приоритетах, которые они отражают. Это наглядная иллюстрация того, что процесс оптимизации — это всегда выбор компромиссного решения из набора альтернатив.

Рекомендация из Части 2: vm.vfs_cache_pressure = 100

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

• Стабильность процессов: Отсутствие аномального роста процессов в состоянии D (блокировка).

• Управление памятью: Наиболее стабильное и предсказуемое использование свопа (наименьший рост).

• Сбалансированность: Умеренные корреляции между метриками, отсутствие экстремальных паттернов.

• Компромисс: Оптимальный баланс между удержанием данных в кэше и их своевременным освобождением.
  Приоритет: Надёжность и предсказуемость долгосрочной работы системы.

Рекомендация из Части 3: vm.vfs_cache_pressure = 150

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

• Производительность диска: Наивысшая пропускная способность (137.5 MB/s) и наименьшие задержки чтения (9.8 мс).

• Эффективность очереди: Самая короткая очередь запросов к диску, что указывает на более эффективную обработку.

• Разгрузка CPU: Наименьшая нагрузка процессора в режиме ожидания I/O (wa).

• Механизм: Агрессивное освобождение кэша снижает конкуренцию (contention) за оперативную память.
  Приоритет: Максимальная скорость обработки данных и минимизация времени выполнения задач.

Заключительный вывод по выбору значения

Обе рекомендации верны в своих контекстах. Выбор между 100 и 150 — это классический инженерный компромисс между «быстро» и «стабильно».

• Для продакшен-среды, где критически важны предсказуемость, стабильность и отсутствие аномалий (внезапные блокировки процессов), следует придерживаться рекомендации vm.vfs_cache_pressure = 100 (или диапазон 90-110).

• Для выделенных ETL-задач или пакетной аналитической обработки, где ключевая цель — минимизировать время выполнения и диск является подтверждённым узким местом, можно обоснованно применить значение vm.vfs_cache_pressure = 150 для получения максимальной пропускной способности, отдавая себе отчёт в потенциально возросшей нагрузке на подсистему памяти ядра.

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