htop показывает именно потоки, а не процесы. В плане поедания рамы это не сильно критично.

> top показывает один

H

дело не в потоках, они память кушают на всех )

в вашей ситуации

* отредактировать /etc/my.cnf ( /etc/mysql/my.cnf )
уменьшить выделяемую память на key buffer и другие значения,
это снизит производительность, но и снизит потребление памяти

* рассмотреть возможность использования внешнего mysql сервера

* рассмотреть возможность перехода с mysql на что-то другое.... если возможно

* не жадничать и увеличить ресурсы vps на более высокий тарифный план, или память отдельно, если предлагается хостером

и апач удалить

Удалить apache и nginx, поставить lihttpd. Вместо mysql поставить sqlite.

Why so serious?

Удалить apache и nginx, поставить lihttpd. Вместо mysql поставить sqlite.

Почему так категорично? Есть штуки, которые ни lighttpd, ни nginx не умеют, например раздача SVN'а. Может здесь именно такой случай. Не зря же человек использует nginx в связке с Apache'ем, а не только nginx.

Есть ли смысл держать 2 веб-сервера? Это актуально при высокой нагрузке, однако, с вашими показателями она будет убийственна даже при хитрой конфигурации связки nginx+apache.

Рассмотрите вариант одного веб-сервера (hint: apache2 тяжелее nginx).

MySQL можно долго и продуктивно точить. Но опять же, а стоит ли в важих условиях? Может стоит посмотреть в сторону более лёгких субд. sqlite вроде бы не плох.

Много потоков это нормально. С субд много памяти уходит на кеширование в памяти.

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

Всем спасибо за наводку на правильный путь- заюзаю lihttpd и sqlite

возможен такой вариант, для php есть патч php-fpm, в 5.3 уже включен в основную поставку, надо только с ним собрать


lighttpd поддерживает fastcgi, nginx кстати тоже,
недостаток fastcgi что он запускает большое число интерпретаторов php, и они едят память, в случае php-fpm, на слабой машине можно сделать так

lighttpd , настроен на fastcgi обращение в сокет php-fpm

для сокета работают 2 (минимально) процесса php - управляющий и обработчик, результат для слабой машинки себя оправдывает

lighttpd - 4 Mb RSS
php-fpm (root) - 4 Mb RSS
php-fpm обработчик - от 4 до 30 Мб, в зависимости от сложности скриптов


итого - 38 мб, в сравнении с fastcgi и вызовом интерпретаторов на каждый .php (30 Mb * N) или апачем с mod_php (30-40 Mb * N)
результат очень выгодный, можно вполне уместиться в 100 метров, даже с mysqld

lighttpd 3985 0.0 0.0 4940 1928 ? S Dec10 0:03 /usr/sbin/lighttpd -f /etc/lighttpd/lighttpd.conf
root 4004 0.0 0.1 19844 3408 ? Ss Dec10 0:23 /usr/bin/php-fpm -y /etc/php/fpm-php5/php-fpm.conf
lighttpd 6776 0.0 0.7 30304 14684 ? S 11:32 0:03 /usr/bin/php-fpm -y /etc/php/fpm-php5/php-fpm.conf
lighttpd 6784 0.0 0.7 30304 14532 ? S 11:32 0:01 /usr/bin/php-fpm -y /etc/php/fpm-php5/php-fpm.conf

2+3,5+14,5+14,5 = 34 Mb, при этом у меня 2 резидентных обработчика, но хватит и 1, т.е. может быть 20 Мб RSS

Drupal, Wordpress, tt-rss работают отлично.

Не зря же человек использует nginx в связке с Apache'ем, а не только nginx.

Самая главная причина использования nginx+apache - htaccess. Следующая причина - тупой копипаст при настройке :)

А зачем именно .htaccess? link

Многие php-движки используют .htaccess. Или о чем вопрос вообще?

Смысл в том, что у nginx есть свой варинт реализации тех же механизмов. Даже переписывать автосгенерированные файлы особо не надо.

если перезапускать рабочий процесс апача после ~30 обращений то он ест около 20 метров (cms joomla) + nginx= 23метра (для небольшой нагрузки хватает). в общем вы меня расстроили - lighttpd я конечно попробую но интузиазм увял.

а мне кажется что для джумлы php-fpm на лайти (ну если хотите можете и с nginx fastcgi поразбираться) вполне сгодится, и да , там есть перезапуск рабочего процесса после определенного числа запросов, если нужно. Вообщем php-fpm того стоит, возни конечно много с пересборкой php, в зависимости от дистрибутива, хотя в некоторых оно уже и есть.

поставила, никаких проблем абсолютно, все работает,
php-fpm кушает 25 метров на процесс (достаточно 1-2 процессов)

http://s42.radikal.ru/i095/1012/3c/fd28a04f85d8.png

ну разве что придется поискать какие правила писать для «чистых ссылок» mod_rewrite

>php-fpm

а его к апачу можно прикрутить? а то сейчас юзаю apache2+mod_fastcgi+phpcgi и впринципе устраивает, но хотелось бы чтобы процессов пыха было поменьше :)
p.s. на другие веб сервера переходить не хочу, апач меня на 100% устраивает...

вроде как можно, только mod_fastcgi придется сменить на mod_cgid , который умеет работать с сокетами.

хотя можно и через директивы

FastCgiExternalServer /var/www/html/fake.handler -host 127.0.0.1:9000
AddType application/x-httpd-fastphp5 .php
Action application/x-httpd-fastphp5 /fake.handler


fake.handler может не существовать, сокет для ФПМ кажется указать нельзя, только повесить на tcp порт, но это тоже вариант.

Поделюсь своим опытом, хоть и оффтоп, но возможно будет полезно. Имеется VPS с 512Мб оперативки, виртуализация XEN. Система Debian Squeeze. Вследствие нестабильности работы дистрибутивного php5-fastcgi (висло по непонятным причинам на скриптах убогой самопальной фотогалереи, переписывать которую ни у кого нет желания) пришлось поставить Apache + mod_php5filter. Естественно, столкнулся с проблемой нехватки памяти. Решение оказалось в моем случае вот таким.

Делаем ThreadSafe сборку PHP (если не хочется мусорить на VPS, то поднимаем на локалхосте виртуальную машину с приближенным к VPS набором софта):

1. apt-get source php5

2. apt-get build-dep php5

3. apt-get install devscripts

4. cd php-5.3.3

5. debchange -v 5.3.3-zts

6. Правим debian/rules. В debian/control

echo "apache2:Depends=apache2-mpm-prefork (>> 2.0.52) | apache2-mpm-itk, apache2.2-common" >>debian/libapache2-mod-php5.substvars
echo "apache2:Depends=apache2-mpm-prefork (>> 2.0.52) | apache2-mpm-itk, apache2.2-common" >>debian/libapache2-mod-php5filter.substvars

Правим так

echo "apache2:Depends=apache2-mpm-prefork (>> 2.0.52) | apache2-mpm-worker (>> 2.0.52) | apache2-mpm-itk, apache2.2-common" >>debian/libapache2-mod-php5.substvars
echo "apache2:Depends=apache2-mpm-prefork (>> 2.0.52) | apache2-mpm-worker (>> 2.0.52) | apache2-mpm-itk, apache2.2-common" >>debian/libapache2-mod-php5filter.substvars

Также в описания целей configure-apache2-stamp, configure-apache2filter-stamp, configure-cgi-stamp, configure-cli-stamp добавляем опцию --enable-maintainer-zts.

7. Для корректной сборки потребовалось удалить некоторые патчи, включенные в сорсы мейнтейнерами. Это use_system_crypt_fixes.patch, use_embedded_timezonedb.patch, use_embedded_timezonedb_fixes.patch, CVE-2010-4150.patch и на этом вроде все (догадаться какие мешают сборке нетрудно из сообщений об ошибках, приводить полный список смысла нет, так как патчи добавляются/удаляются мейнтейнерами когда они захотят).

8. Запускаем в каталоге с сорцами пакета dpkg-buildpackage и ждем, на выходе получим threadsafe-сборку PHP.

9. Инсталлим apache2-mpm-worker вместо apache2-mpm-prefork, ставим собранный нами модуль для PHP (lipapache2-modphp5 или libapache2-modphp5filter, в принципе все равно).

Мой конфиг, секция модуля worker:

<IfModule mpm_worker_module>
    StartServers               1
    MaxClients                32
    MinSpareThreads            1
    MaxSpareThreads            6
    ThreadsPerChild           32
    MaxRequestsPerChild     5000
</IfModule>

Апач забинден на 127.0.0.1, запросы на него идут через Squid, который кэширует статику на 10 минут. При не самой слабой и не самой сильной нагрузке (40-50 юзеров лазают по форуму на phpBB3/PostgreSQL, используются persistent connections, из-за чего тредов апача и процессов постгреса висит около 32 штук. Кроме того, используется XCache, выделено 24мб под кэш для байткода и 1мб под кэш переменных.) потребление памяти процессом апача держится на уровне 70мб, при этом судя по результатам замеров встроенной в phpBB мерилкой работает все это дело на глаз процентов на 10 быстрее связки php-fastcgi + lighttpd + XCache и уж точно быстрее mpm-prefork + дистрибутивный mod_php5, которая еще и ела больше памяти. При желании потребление памяти можно серьезно (на треть где-то) уменьшить, выкинув лишние модули апача и расширения PHP, указав меньшее количество бездействующих тредов апача и запретив использование постоянных соединений с БД, но это негативно скажется на производительности...

P.S. на данный момент пакеты Apache2, PHP5 и постгреса пересобраны с помощью icc (потребовался большой бубен при сборке PHP с --enable-maintainer-zts, не один я на эту проблему натыкался), потребление памяти несколько уменьшилось (не смогу точно сказать, насколько), ну и посты с большим количеством ббкодов стали парситься явно быстрее.