madspectator
на secondary у меня raid-1 nvme, на primary raid-10 nvme
yopp
Вы можете посмотреть на iostat под нагрузкой
madspectator
Я не очень понимаю, что там смотреть, на ща попробую сделать
madspectator
replWriterThreadCount = 128 сделал на secondary и запустил, интересно, что пока не вижу серьёзной просадки
yopp
iostat -x покажет вам расширенную статистику. Вас интересуют *await и aqu-sz
madspectator
А интервал какой лучше делать?
yopp
Да не очень важно :) можно раз в секунду
madspectator
ох, оно там красным подсвечивает 100 в колонке %util
madspectator
avg-cpu: %user %nice %system %iowait %steal %idle
28.78 0.00 4.03 13.11 0.00 54.08
Device r/s w/s rkB/s wkB/s rrqm/s wrqm/s %rrqm %wrqm r_await w_await aqu-sz rareq-sz wareq-sz svctm %util
nvme0n1 222.33 2804.33 4933.33 138690.67 0.33 25.33 0.15 0.90 9.42 1.57 5.18 22.19 49.46 0.33 100.00
nvme1n1 1596.33 2810.67 36754.67 138677.33 0.33 18.67 0.02 0.66 0.66 0.11 2.25 23.02 49.34 0.23 100.27
md1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
md0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
md2 1814.00 34.67 41613.33 1788.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 22.94 51.58 0.00 0.00
https://dumpz.org/cYmBF59NkPd8/text
madspectator
https://dumpz.org/cYmBF59NkPd8/text - во тут читаемо, вроде
madspectator
Причём на primary сервере в колонке %util у меня написано 10-20 ))
yopp
%util достаточно бесполезная метрика
yopp
она из времени когда у хранилищ была глубина очереди 1
madspectator
https://dumpz.org/bSMnQznCgKf8/text/ — это iostat -x 3 на primary
madspectator
там по-моему всё в память пишется ))
madspectator
и иногда на диск сбрасывается
yopp
есть ощущение что у вас secondary делают initial sync сейчас
yopp
а на primary вообщ нет нагрузки 🙂
yopp
yopp
yopp
что-то у вас не так идёт 🙂
madspectator
https://dumpz.org/bH7KWFCfSGdK/text/ - а так? это primary
yopp
это уже похоже, да
madspectator
Возможно, первый раз я сделал iostat на primary, когда случился лаг из медленного secondary
madspectator
Эх, лаги пошли. replWriterThreadCount=128 точно не помогает ))
yopp
но очень странно что на secondary у вас 130МБ/с записи на каждый из дисков, а на primary по 4МБ/с
yopp
(md* вообще показывает почему-то погоду на марсе)
yopp
а у вас рейд в healthy состоянии?
yopp
на этих серверах нет других сервисов?
madspectator
на этих серверах нет других сервисов?
на секондари у меня ещё собсственно парсер запущен )) но он вроде на диск не пишет
madspectator
но очень странно что на secondary у вас 130МБ/с записи на каждый из дисков, а на primary по 4МБ/с
Так я грю, на primary у меня 256gb ram, там всё кэшируется в памяти, а потом пишется иногда на диск
madspectator
Или mongodb не так работает?
yopp
Так я грю, на primary у меня 256gb ram, там всё кэшируется в памяти, а потом пишется иногда на диск
на тысячах update qps маловероятно что у вас будут такие цифры
yopp
wt делает снепшоты раз в 100мс и или каждые N (из головы не помню) мегабайт накопившихся грязных страниц
yopp
если у вас большой поток обновлений то это будет видно
yopp
посмотрите на iotop на secondary
yopp
кто создаёт такую нагрузку
madspectator
wkB/s дожлно быть одинаковым в iostat secondary и primary, я правильно понимаю?
yopp
ну +/-, да
yopp
на secondary обычно поменьше
madspectator
Весь iotop успешно засран 128 ReplWriter тредами mongodb :), на secondary
yopp
а в каком состоянии сейчас secondary?
yopp
а какой лаг репликации?
yopp
rs.printSecondaryReplicationInfo()
yopp
тогда io-картинка на primary скорее всего обусловлена тротлингом из-за flowControl, а secondary нодам действительно не хватает пропускной способности
yopp
12s лага это больше чем дефолтные 10s у flowControl
yopp
по размеру окна репликации делённого на размер rs.oplog, можно примерно прикинуть сколько данных генерируется
yopp
точнее наоборот, размер на окно
yopp
потому что flowControl тротлит запросы пока secondary не уменьшат лаг репликации ниже flowControlTargetLag
yopp
так как у secondary полно оплога чтоб его выгребать, то на стороне primary вы видете результат тротлинга, а у secondary как они пытаются с primary сгрести оплог
yopp
а ещё число 130мб плохо тем, что это примерно 1 гигабит 🙂
yopp
возможно сверху к нехватке дискового io вам ещё и пропускной способности сети не хватает
yopp
да
yopp
возможно ваше хранилище ещё по ширине может прокачать больше 130МБ/с, но вот сети уже не хватает
yopp
попробуйте установить net.compression.compressor в zlib на всех нодах
yopp
а, уже по дефолту
yopp
Starting in version 4.2, mongod and mongos instances default to both snappy,zstd,zlib compressors, in that order.
yopp
в этом случае вам лучше вытащить парсеры на отдельный сервер, который по отдельному линку подключить к primary
yopp
а сколько у вас сети всего?
yopp
если у вас там гигабитный линк между всеми нодами, то вашу проблему это не решит 🙂
yopp
вам лучше уточнить у поддержки какой линк у вас между нодами и какой линк в мир
yopp
1GBit порт может быть в мир, а между серверами например 10G на стойку
yopp
на всех нодах?
yopp
а между secondary?
yopp
secondary могут не напрямую с праймари реплицироваться
yopp
а например node1 -> node2 -> node3 (см syncSource в rs.status())
yopp
я вам рекомендую воткнуть прометея, графану и как минимум node exporter
yopp
плюс ppm
yopp
https://www.percona.com/software/database-tools/percona-monitoring-and-management
yopp
сейчас у вас visibility о том что происходит
yopp
вам нужно увидеть происходящее в динамике и сравнить ключевые метрики
yopp
загрузка дисков / загрузка сети / qps и replicatin lag
yopp
сейчас у вас нет единой картины, так как вы сравниваете метрики из разного времени
yopp
не факт 🙂
yopp
мне вот очень интересно откуда 130МБ/с записи берутся, если по сети 60 мегабит
yopp
60 мегабит это меньше 10 мегабайт