Назад | Перейти на главную страницу

Рост кеш-памяти ОС в ОЗУ приводит к высокой загрузке ЦП системы

У меня странная проблема с сервером, которую я никогда раньше не видел. На машине с ~ 30 ГБ оперативной памяти с приложением, которое занимает ~ 10 ГБ (распределено по сотням процессов). Со временем ОС начинает заполнять свободную оперативную память кешем и буферами (совершенно нормально для Linux). Я видел, как это происходило раньше без каких-либо проблем, но на этой машине, когда объем пустой ОЗУ уменьшается, это сводит с ума ЦП системы (100% на 8 ЦП в течение ~ 3 минут) примерно на отметке 256 МБ. Я предполагаю, что ОС использует весь этот процессор, чтобы перетасовать память, чтобы вернуть немного свободного места.

Из того, что я понимаю в управлении памятью Linux, предполагается, что он должен использовать столько свободного места в ОЗУ, сколько может для кеширования на уровне ОС, но затем передать его любым приложениям, которые в нем нуждаются, когда их спросят, и из прошлого опыта это не было травмирующим опытом для процессора. Так происходит все время. Так почему здесь могло быть иначе?

Я прилагаю небольшую часть вывода vmstat для связанных метрик (собираемых каждые 2 секунды). Вы можете видеть, где системный ЦП (14-й столбец, 3-й справа) начинает загружаться, когда объем свободной памяти достигает ~ 256 МБ, а затем через 30 секунд становится действительно сумасшедшим.

r    b   swpd  free     buff     cache     si  so  bi   bo    in     cs     us  sy   id  wa
1    0   0     293876   5022848  18797528  0   0   206  1712  20924  12845  29  9    61  1
6    0   0     285324   5022848  18797656  0   0   0    0     18795  11382  23  9    68  0
2    0   0     292320   5022848  18797916  0   0   26   2022  19933  12068  27  10   62  1
3    0   0     264492   5022848  18798196  0   0   14   0     20705  15412  30  9    61  0
3    0   0     254880   5022848  18798804  0   0   190  532   16207  9723   31  8    60  0
17   0   0     255588   5021292  18783092  0   0   24   2     13521  7471   27  42   31  0
3    0   0     288396   5020536  18771496  0   0   0    2     14277  8458   24  29   47  0
4    0   0     299560   5020180  18761296  0   0   0    448   8778   5099   21  30   49  0
2    0   0     290908   5019376  18753656  0   0   0    2     9027   5115   27  19   54  0
7    0   0     306060   5018544  18746740  0   0   38   442   8398   5134   20  17   63  0
1    0   0     317140   5018244  18744252  0   0   46   0     9707   5822   22  17   61  0
4    0   0     282268   5017748  18741836  0   0   12   2     10203  6165   26  12   62  0
1    0   0     322548   5017500  18738024  0   0   2    444   10593  6277   23  16   61  0
4    0   0     314936   5017280  18734564  0   0   6    8     9473   5680   25  15   61  0
13   0   0     316976   5017044  18731128  0   0   0    622   12481  7353   33  17   49  0
5    0   0     324952   5016908  18728552  0   0   10   222   11071  6965   22  13   65  0
2    0   0     324692   5016908  18728344  0   0   0    526   10612  6602   24  10   66  0
3    0   0     312312   5017136  18727644  0   0   156  1050  12316  7472   26  10   63  1
2    1   0     323392   5017260  18726848  0   0   66   26    11643  7152   23  13   64  0
8    1   0     318956   5017124  18723772  0   0   20   518   17042  9543   31  22   46  1
1    0   0     317816   5017124  18725428  0   0   0    2854  11704  6951   21  9    67  3
18   0   0     325136   5014492  18707212  0   0   0    32    7619   3845   16  58   27  0
46   0   0     323508   5012980  18692036  0   0   0    562   3939   917    3   92   5   0
71   0   0     299164   5009680  18675476  0   0   0    6     4696   1304   8   90   1   0
75   0   0     205364   5007744  18657228  0   0   36   340   6699   2556   18  82   0   0
75   0   0     221660   5005956  18636480  0   0   68   0     3942   943    4   95   0   0
84   0   0     223788   5004624  18618380  0   0   0    0     2843   335    3   97   1   0
44   0   0     214956   5002464  18599872  0   0   0    0     4696   1301   5   92   3   0
37   0   0     223804   4999964  18577076  0   0   0    0     3281   521    1   98   0   0
82   0   0     266888   4995768  18557264  0   0   0    1760  4595   766    4   96   1   0
91   0   0     260148   4993964  18541192  0   0   0    0     3780   866    6   94   0   0
74   0   0     279796   4990464  18524980  0   0   0    4     4096   926    4   96   0   0
44   0   0     274796   4984268  18503492  0   0   0    0     6316   2142   3   95   3   0
48   0   0     295616   4981824  18482616  0   0   0    0     2561   227    1   99   1   0

Я также добавляю снимок экрана из инструмента мониторинга, чтобы нагляднее показать, что происходит с памятью. На этом графике нижняя (фиолетовая) линия - это фактическое свободное пространство, оставшееся в ОЗУ, и каждый раз, когда оно достигает 256 МБ, это вызывает скачок ЦП.

Кстати, своп на этой машине отключен (если вы не можете сказать по vmstats).

Я думаю, что процессор используется только для сканирования таблиц страниц, чтобы найти, какие фреймы освободить. Хотя это кажется высоким, у меня есть одна система с маленькими страницами, 400 ГБ ОЗУ, и она не показывает такого драматического поведения. Трудно сказать, что является основной причиной, но я хотел бы предложить обходной путь. Включить значительное количество огромных страниц (через vm.nr_hugepages). Это существенно уменьшит размер таблиц страниц, поскольку огромная страница имеет 2 МБ, что в 512 раз больше, чем маленькая страница. В этой статье описывается решение подобной проблемы..

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