У меня есть около 12 процессов httpd, запущенных для окна RHEL aws, которые никто не запускает в браузере (общий блок разработчиков команды). Вместе эти процессы занимают более 1,8 ГБ на устройстве разработчика, и я видел до 6 ГБ на производстве. Каждый из этих процессов потребляет около 800 МБ на один ps aux. Я проверил одну из них и оставил ее на время, чтобы найти:
<venv>/django/contrib/flatpages/templatetags/analytical 0x7fff37ef41a0) = -1 ENOENT (No such file or directory)
<venv>/django/contrib/flatpages/templatetags/analytical.py, O_RDONLY) = -1 ENOENT (No such file or directory)
<venv>/pagination/templatetags/expert_tags.py, O_RDONLY) = -1 ENOENT (No such file or directory)
<venv>/django/templatetags/raven.py, O_RDONLY) = -1 ENOENT (No such file or directory)
<vevn>/django_extensions/templatetags/raven.py O_RDONLY) = -1 ENOENT (No such file or directory)
Есть; без шуток, тысячи этих ENOENT сообщений всего за 5 минут. Все типы разных файлов.
Ряд 3 другие процессы показывают кое-что тоже интересное
read(4, 0x7fff37efa00f, 1) = -1 EAGAIN (Resource temporarily unavailable)
Любым способом узнать, какой Ресурс упоминается здесь?
Я не специалист по программированию ОС, но полагаю, это ненормально? Есть идеи, как я могу узнать, что вызывает это? Как это предотвратить?
Как ни странно, этот raven.py, конечно, действительно отсутствует, но у нас есть сторонняя библиотека в виртуальном окружении, которая называется
raven (3.5.1)
Хотя до сих пор не совсем уверен, почему так много ENOENT, было неправильное понимание конфигурации apache. Я сделал предположение, что mod_wsgi работает как демон, когда он работал во встроенном режиме. В разделе apache worker.c установлено количество процессов 8 с расширением 25, и поэтому было так много резервных процессов.
Каждый процесс резервирует около 800 МБ пространства виртуальной машины и около 120 МБ ОЗУ. После того, как mod_wsgi был изменен на демон, эти цифры упали до 200 МБ для виртуального пространства и 8 МБ для ОЗУ! Общее потребление памяти apache снизилось с 1 ГБ до 64 МБ!