После нескольких дней интенсивных проб и ошибок, я рад, что могу сказать, что понял, где было узкое место, и опубликую его здесь, чтобы другие люди могли извлеките пользу из моих выводов.
Проблема заключается в подключениях pub / sub, которые я использовал с socket.io, и, в частности, в RedisStore, используемом socket.io для обработки межпроцессного взаимодействия экземпляров сокета.
Осознав, что я могу легко реализовать свою собственную версию pub / sub с помощью redis, я решил попробовать и удалил redisStore из socket.io, оставив его с хранилищем памяти по умолчанию (я не необходимо транслировать на всех подключенных клиентов, но только между двумя разными пользователями, подключенными, возможно, к разным процессам)
Первоначально я объявил только 2 глобальных соединения redis x процесс для обработки pub / sub на каждом подключенном клиенте, и приложение использовало меньше recources, но на меня по-прежнему влияет постоянный рост загрузки ЦП, поэтому мало что изменилось. Но затем я решил попытаться создать 2 новых подключения к redis для каждого клиента, чтобы обрабатывать их pub / sub только в своих сеансах, а затем закрыть подключения после отключения пользователя. Затем, после одного дня использования в производстве, ЦП все еще был на уровне 0-5% ... бинго! никаких перезапусков процесса, никаких ошибок, с производительностью, которую я ожидал. Теперь я могу сказать, что node.js великолепен, и я счастлив, что выбрал его для создания этого приложения.
Не ответ как таковой, так как ваш вопрос больше похож на сказку, чем на вопрос с одним ответом.
Просто хочу сказать, что я успешно построил сервер node.js с socket.io, обрабатывающим более 1 миллиона постоянных соединений со средней полезной нагрузкой сообщения 700 байт.
Карта сетевого интерфейса на скорости 1 Гбит / с вначале была насыщенной, и я наблюдалось МНОГО ожидания ввода-вывода от событий публикации для всех клиентов.
Удаление nginx из роли прокси также вернуло драгоценную память, потому что достижение одного миллиона постоянных подключений с помощью только ОДНОГО сервера - сложная задача по настройке конфигураций , приложение и настройка параметров ОС. Имейте в виду, что это можно сделать только с большим количеством ОЗУ (около 1 миллиона подключений к веб-сокетам потребляют около 16 ГБ ОЗУ, с node.js, я думаю, использование sock.js было бы идеальным для низкого потребления памяти, но пока socket.io потребляет столько же).
Эта ссылка была моей отправной точкой для достижения такого объема соединений с узлом. Помимо того, что это приложение на Erlang, вся настройка ОС в значительной степени не зависит от приложения и должна быть полезна всем, кто стремится к постоянным соединениям (веб-сокеты или длительный опрос).
HTH,
У вас есть исходный код для сброса? Может быть подключения к базе данных не закрыты? Процессы, ожидающие HTTP-соединений, которые никогда не закрываются.
Можете ли вы опубликовать журналы?
Выполните ps -ef и убедитесь, что ничего не запущено. Я видел, как веб-процессы оставляют зомби, которые не умрут, пока вы не убьете -9. Иногда выключение не работает или не работает t работают полностью, и эти потоки или процессы будут содержать ОЗУ, а иногда и ЦП.
Это может быть бесконечный цикл где-то в коде или сбойный процесс, удерживающий соединение с базой данных.
Какие модули NPM используют? Все ли они самые свежие?
Вы ловите исключения? См .: http://geoff.greer.fm/2012/06/10/nodejs-dealing-with-errors/ См .: https://stackoverflow.com/questions/10122245/capture-node-js-crash-reason
Общие советы:
http://blog.nodejitsu.com/keep-a-nodejs-server-up-with -forever
http://hectorcorrea.com/blog/running-a-node-js-web-site-in-production-a-beginners-guide
https://stackoverflow.com/questions/1911015 /how-to-debug-node-js-applications
https://github.com/dannycoates/node-inspector
http://elegantcode.com/2011/01/14/taking-baby-steps -with-node-js-debugging-with-node-Inspector /