Цікавий випадок сьогодні з
#MongoDB. На одному із secondary в replica set раптово злетіло навантаження на диск до 80-90%. Почав копати - виявилось, що йшло створення індексу на колекції з 16 мільйонами документів (розробники додали індекс та забули попередити). На primary та hidden secodary індекс побудувався з невеликим додатковим IO, але на доступному для запитів secondary активно молотив диск, але чому так довго і так важко?
Виявилось що WiredTiger cache був заповнений під зав'язку і постійно виганяв сторінки щоб читати нові - класичний cache thrashing. В результаті система почала свапувати, своп заповнився повністю (8GB/8GB), і
#MongoDB почав читати та писати через swap - звідси і дисковий ад.
Вирішення виявилось простим - вимкнути swap. До речі
#claude сказав не робити цього, бо буде
#OOM та mongodb процес помре першим.
Я все ж таки зробив swapoff -a. Команда працювала 1.5 години :-(
#Ubuntu поступово відвойовувала місце в свопе за рахунок зменшення дискового кешу. На скріншоті біла полоса - це коли почався процес зменшення свопа - система була перевантажена, що не могла відправляти телеметрію.
Дані повернулись в RAM і IO впав до норми буквально одразу.
Ще
#claude радим поставити`vm.swappiness=1`, але не дивлячись на це система усе одно використовувала своп, бо MongoDB віджирав усю доступну памʼять від свої кеші.
Треба спробувати обмежети wiredTiger розмір кеша, щоб він не добирався до свопа.
Rad Web Hosting
Jobs for Developers
InfoQ
El laboratorio de Rafa
Hagen J
ДевоПес