У меня проблема с одним из моих приложений Rails, которое работает на 365 МБ VPS, что, похоже, не очень много. Когда одновременно работает более 3-5 пользователей, ему не хватает памяти, и он начинает использовать подкачку, что чертовски медленно.
Когда я смотрю в top, Я вижу, что существует много порожденных экземпляров mysql (гораздо больше, чем процессов Rails). Это нормально?
Как вы рекомендуете уменьшать приложение для слабой памяти enviromnent?
Я использую Ubuntu 9.04, Apache2.2 с модом пассажира, MySQL 5.075 и Ruby 1.8.7
edit: После ваших предложений я обновил VPS до 540 МБ, чего на данный момент кажется достаточно. Однако я просто бедный студент, поэтому я не могу закачать слишком много денег в какой-то проект, который делаю в основном для себя, пока он не начнет хоть что-то окупать.
Вы потратите много времени (и, следовательно, денег) на настройку параметров для возможно произвести небольшую экономию памяти. Вы получите гораздо больше прибыли, просто обновив оперативную память на своем VPS.
Будет несколько потоков mysql, а не процессов. Некоторые версии «Top» и «ps» показывают потоки, как если бы они были отдельными процессами.
MySQL можно настраивать сколько угодно. Лучший способ настроить его - использовать только один движок для всех ваших таблиц - если вы используете InnoDB, используйте ТОЛЬКО InnoDB.
Затем настройте буферы по своему усмотрению - основными из них являются кэш ключей MyISAM и пул буферов innodb. Если вы используете только MyISAM, полностью отключите движок innodb с помощью skip-innodb в my.cnf.
Что касается Apache, запускайте как можно меньшее количество MaxClients; либо отключите поддержку активности, либо установите очень малое время ожидания - соединения проверки активности по-прежнему будут связывать (здоровенный) процесс Apache.
Конечно, выполнение любого из этих действий может отрицательно сказаться на производительности, поэтому протестируйте его на непроизводственной системе, если вас беспокоит снижение производительности.
Возможно, будет выгоднее просто купить больше плунжера, чем тратить время на настройку такой крошечной коробки. В нашей работе у каждого разработчика есть лезвие с 16 Гбайт только для тестовых целей. Это считается разумным и не очень дорогим.
lowendbox.com хороший сайт, достойный закладки, связанный с этой проблемой (оптимизация серверов с низким объемом памяти)
Следующее, конечно, не соответствует вашей существующей настройке, но рассмотрите возможность перехода на более легкий httpd, например nginx och lighttpd. Любой из этих двух должен сэкономить вам много оперативной памяти, по крайней мере, на статическое http-соединение. Пассажир доступен для nginx.
Вам нужно будет больше копнуть и выяснить, что именно использует ваша память, сколько времени занимает каждый процесс, искать потенциальные утечки и так далее. Но мой совет будет повторять другие: вместо этого используйте больше оперативной памяти. 365 МБ - это арахис, и он вообще не масштабируется. Проблема усугубляется вашим выбором фреймворка - ознакомьтесь с опытом Twitter Вот.
Выбранный выход:
Все удобные методы и синтаксический сахар, которые делают Rails таким удовольствием для программистов, в конечном итоге оказываются абсолютно суровыми с точки зрения производительности. Как только вы достигнете определенного порога трафика, вам нужно либо убрать все дорогостоящие аккуратные вещи, которые Rails делает для вас (RJS, ActiveRecord, ActiveSupport и т. Д.), Либо переместить медленные части вашего приложения из Rails, либо и то, и другое. Также стоит упомянуть, что на данный момент ни у кого не должно быть сомнений в том, что сам Ruby работает медленно.