Я запускаю один экземпляр gcloud g1-small с Debian для работы одного сервера Node и одного сервера Apache. Я использую Node Bouncy для перенаправления HTTP-запросов на Node или Apache в зависимости от req.headers.host. Каждый из двух моих веб-сайтов имеет низкий трафик, менее 10 тысяч обращений в день.
Примерно через две недели непрерывной работы мои веб-сайты Apache и Node перестали отвечать. Мне тоже не удалось подключиться к экземпляру через SSH. После перезагрузки и просмотра логов я обнаружил следующее:
/var/log/kern.log:
kernel: [timestamp] TCP: out of memory -- consider tuning tcp_mem
(multiple times)
/var/log/apache2/error.log:
[Timestamp] [core:warn] [pid 573] (105)No buffer space available: AH00056: connect to listener on 0.0.0.0:8001
(multiple times)
В моем файле журнала узла ничего не было.
Как я могу предотвратить повторение этой ошибки?
Недавно мы столкнулись с интересной производственной проблемой. Это приложение работало на нескольких экземплярах AWS EC2 за Elastic Load Balancer. Приложение работало на ОС GNU / Linux, Java 8, сервер приложений Tomcat 8. Внезапно один из экземпляров приложения перестал отвечать. Все остальные экземпляры приложений обрабатывали трафик должным образом. Всякий раз, когда HTTP-запрос отправлялся этому экземпляру приложения из браузера, мы получали следующий ответ, который нужно было распечатать в браузере.
Ошибка прокси
Прокси-сервер получил недопустимый ответ от вышестоящего сервера. Прокси-сервер не смог обработать запрос GET /.
Причина: ошибка чтения с удаленного сервера
Давайте посмотрим, как мы решили эту проблему, назначив значения для этих свойств на сервере:
net.core.netdev_max_backlog = 30000 net.core.rmem_max = 134217728 net.core.wmem_max = 134217728 net.ipv4.tcp_max_syn_backlog = 8192 net.ipv4.tcp_rmem = 4096 87380 67108864c108864t.ip_w4 net.ip_w4
TCP: недостаточно памяти - рассмотрите возможность настройки tcp_mem
Я увеличил некоторые значения TCP, чтобы использовать больше памяти. Я добавил эти строки в сценарий запуска сервера:
sysctl -w net.ipv4.tcp_mem='116730 155640 233460'
sysctl -w net.ipv4.tcp_max_orphans='24576'
Хотя это не должно решить проблему навсегда, это должно дать мне больше времени безотказной работы до того, как сервер выйдет из строя. Перезагружал сервер раз в месяц и пока никаких проблем не было.
Однако реальным решением было бы исправить утечку памяти, которая в первую очередь вызывает эту проблему.