Нода была одна на винде, после чего их стало 2 на windows docker, сейчас 2 на linux docker. Вторая работает без нареканий. Подскажите куда копать вообще
Я не уверен какие инструменты есть на линуксе для мониторига файловой системы – может strace? – но я бы попробовал посмотреть на какие конкретно файлы нода трогает.
Моя нода (на freebsd) на старте хрустит дисками около часа, хотя там сейчас совсем немного данных (пол терабайта) и на сервере куча свободной памяти (для кеша метаданных). Если в этот момент посмотреть на что делает файловая система – там storage node перебирает все файлы в хранилище.
Я пытаюсь выразить что надо убедится что нода не щупает одни и те же файлы по кругу; в этом случае рано или поздно она закончит. Можно попробовать добавить RAM на сервер – линукс будет его использовать как кеш файловой системы и может чуть ускорить процесс (хотя на старте кеша все равно нет, и потому скорее всего никакой разницы не будет) но зато потом вся метадата будет закеширована и теоретически это должно помочь ноде обрабатывать запросы быстрее.
Говорит о том, что ваш диск достаточно медленный, чтобы в эту БД не успевала добавляться информация об использованной полосе пропускания.
Возможно пора перемещать БД на SSD: How to move DB’s to SSD on Docker
А какую файловую систему вы используете?
Дык если клиент хочет маленький кусочек, все равно нужно будет где то его из большого выковыривать — либо на ноде, тогда экономии дисковой активности все равно не получится, или на клиенте, тогда лишний трафик гонять придётся.
Я думаю все же решение — куча рама на ноде чтоб всю метадату закешировать.
Ну и чтоб два раза не вставать — чтоб датабазы не тормозили — slog на optane, это если zfs, чтоб синхронные врайты оптимизировать.
@arrogantrabbit прав, к тому же на узле хранятся кусочки из разных сегментов файлов разных клиентов. То есть запросы всегда будут на кусочки, а не пакет. Упаковывать и распаковывать излишняя нагрузка как на диск, так и на процессор и память. Так что либо использовать один узел-один диск и родная файловая система - для Linux ext4, для Windows NTFS, либо монструозные дорогие массивы с SSD прослойкой и большим количеством RAM.
V printsipe, u menja na 1 sisteme windows rabotaet 8 nodov, zdelan cache na NVME 1TB, vse bazy dannyh nahodjatsa na SSD s OS. Rabotaet kak chasy. Dazhe posle restarta proverka zanjala vsego okolo 6 chasov, pri tom 4to nody po4ti vse polnye po 4TB primerno
Можно сюда копнуть: --storage2.piece-scan-on-startup=false
хоть разработчики вроде и не рекомендуют, но если диск не вывозит после рестарта, то вот это спасет.
А почему ССД должен умереть так быстро? Там не так много записей чтоб изтерзать все ячейки за такое короткое время, даже с учетом write amplification. И потом всегда можно мониторить и заменить ссд когда ресурс записи подходит к концу.
И потом многие (все?) ссд помирают в readonly. Можно будет скопировать данные тогда.
USB флешки конечно это совсем другой разговор. Они плохо контролируют износ и если в них записывать в один и тот же сектор (что базы данных часто делают) они реально могут износить несколько физических секторов в ноль.
Сравнивать с играми не стоит, там другие цели. Текстуры (всегда сжатые, кстати) читаются один раз, на старте, и в основном последовательно, поэтому даже если произвольный доступ к файловой системе занимает время (seek latency) для одноразового чтения текстур это несущественно.
Тут ситуация другая: произвольный доступ подразумевается и ожидается с самого начала и до конца; под него надо оптимизировать.
Склеивая файлы можно сделать только хуже: это совсем не поможет уменьшить время доступа к самому файлу (часть которого — чтение метаданных из директории — прекрасно можно закешировать) но зато добавит ещё один seek внутри файла (который закешировать уже не получится)