Оптимизация производительности: печать журнала приводит к увеличению размера кэша страниц.

1. Есть проблема

Вчера получил сигнал мониторинга контейнера, этот сервис в основном используется для разработки интерфейса и стыковки. Обычно трафик относительно небольшой, поэтому используется контейнер с лимитом памяти 2G.

Используйте jinfo для проверки того, что параметр запуска jvm является флагом виртуальной машины ault: 357564416 - XX:OldSize=716177408 -XX:+PrintGC -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap -XX:+UseCompressedXClassPointers: +UseCompressedOops -XX:+UseFastUnorderedTimeStamps -XX:+UseParallelGC

Проверьте информацию о 24-часовом мониторинге контейнера.Фактическое использование памяти контейнера выглядит следующим образом.Вы можете видеть, что фактическое использование памяти экземпляром, представленным зеленой кривой, стремительно растет.

Используйте команду top, чтобы просмотреть использование процесса Java следующим образом.

Используйте команду top -H -p для просмотра использования потока в процессе Java следующим образом.

После проверки некоторой информации мониторинга я обнаружил, что информация мониторинга в основном точна, память контейнера ограничена 2 ГБ, процесс службы использует около 1,3 ГБ, но на самом деле служба использует более 2,3 ГБ памяти, а кэш-память страниц ограничена. большой.

2. Анализ проблемы

2.1 Анализ в JVM

Используйте для просмотра следующей команды и не обнаружил наличия крупных объектов

Используйте для вывода информации о стеке и используйте инструмент mat для анализа результатов следующим образом: в стеке нет больших объектов. Похоже проблема не в куче jvm.

2.2 Анализ системы Linux

Используйте , чтобы проверить состояние памяти процесса и посмотреть, не является ли это проблемой 64M, вызванной функцией malloc, о которой сказал Бог.Результат показывает, что нет особенно большой памяти место выделено.

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

В настоящее время нет утечек или больших выделений памяти внутри и вне кучи. Кажется, я могу спросить только начальника эксплуатации и обслуживания. Начальник эксплуатации и обслуживания рекомендует использовать для проверки удельного потребления памяти.Видно, что память, используемая для чтения и записи файлов, очень велика Похоже, что основные факторы изменения вызваны резко возросшей пропускной способностью ввода/вывода сети или диска сервера.

# cat /proc/meminfo
…
MemTotal:       129778440 kB 内存总量
MemFree:         7533696 kB  空闲内存总量
MemAvailable:   52198264 kB  有效内存量
Buffers:          850716 kB  内存中写完的东西缓存起来，这样快速响应请求，后面数据再定期到硬盘上
Cached:         48735240 kB  内存中读完缓存起来内容占的大小
SwapCached:            0 kB  硬盘上交换分区大小
Active:         88164904 kB  活跃使用中的高速缓冲存储器页面文件大小
Inactive:       23182084 kB  不经常使用中的告诉缓冲存储器文件大小
Active(anon):   26384472 kB  活跃的匿名内存（进程中堆上分配的内存,是用malloc分配的内存）
Inactive(anon):     2672 kB  不活跃的匿名内存
Active(file):   61780432 kB  活跃的file内存
Inactive(file): 23179412 kB  不活跃的file内存  
……
Shmem:             22056 kB 已经被分配的共享内存大小
……
SReclaimable:    8194524 kB 可收回slab的大小

Поскольку трафик самой службы очень мал, проблема, вызванная сетевым вводом-выводом, исключена. путем печати журнала. Используйте для просмотра, вы можете увидеть, сколько содержимого файла в каталоге находится в памяти, здесь вы можете увидеть, что память, занимаемая файлом журнала для чтения и записи, на самом деле составляет 900 МБ, здесь вы можете видеть, что лог-файл читается и пишется.Парит кэш страниц, постоянно занимая память, используемую контейнером.

3. Решение проблем

Используйте команду arthas для динамической настройки уровня печати журнала экземпляра с информации на lerror, чтобы уменьшить объем печати журнала. Таким образом, фактическое использование памяти и page_cache контейнера внезапно прекратится.

Но после ночи фактическое использование памяти снова взлетело.Проверив код, мы видим, что логи Rocketmq-client печатаются в другие места отдельно.Здесь есть еще одно явление.Спустившись вниз, мы обнаружили, что этот период это время оказалось временем, когда был свернут лог-файл Rocketmq-client.Мы перенастроили конфигурацию печати лог-файла следующим образом, а память контейнера и page_cache, использованные позже, упали до нормального уровня.

4. Обзор проблемы

4.1 Знания о кэше страниц

Кэш страниц, также известный как pcache, его китайское название — кеш-память страниц, называемая кешем страниц. Размер страничного кеша — одна страница, обычно 4К. существуетlinuxПри чтении и записи файлов он используется длятайникЛогическое содержимое файла может ускорить доступ к изображению и данным на диске.Поэтому кеш страницы может эффективно уменьшить ввод-вывод и повысить скорость ввода-вывода приложения.Вы можете использовать /proc/meminfo , free, /proc/vmstat и другие средства для мониторинга. Однако память, занимаемая кешем страниц, слишком велика, и это также вызовет такие проблемы, какНагрузка на сервер зашкаливает, задержка ответа службы имеет большой задир, а средняя задержка доступа к службе значительно увеличиваетсяИ другие вопросы.

4.2 Влияние на скорость чтения и записи файлов

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

использованная литература

Ооо.ОПИСАНИЕ .com/fear/933 from from 2...664Подробное объяснение /proc/meminfo

woohoo.cn blog.com/coldplay и E…использование vmtouch

blog.CSDN.net/top\_ex красивая или…Механизм обратной записи кеша тестовой страницы Java

Привет. Frees Ion.com/article/551 ...Проверка производительности чтения и записи файлов _ _

blog.CSDN.net/U012501054/…Сведения о памяти Linux