LINUX.ORG.RU
решено ФорумAdmin

mysql на слабом vps


0

2

имеется vps на openvz 100 Мб оперативы. Юзаю его как вэб хоститнг- nginx<->apache<->php<->mysql. Проблема - нехватка памяти. нжиникс и апач я отконфигурил (1 процесс nginx и 1 процесса с апачем) Простой конфигур mysqld я тоже сделал. Cмотрю вывод htop вижу 12 потоков mysqld!!! (top показывает один)

можно ли как-то уменьшить их количество?

гуглил, офф документацию уже скачал но никакого упоминания о этом я не нашел

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

ventilator ★★★
()

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

H

YAR ★★★★★
()

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

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

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

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

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

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

Sylvia ★★★★★
()
Ответ на: комментарий от eval-apply

Why so serious?

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

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

Camel ★★★★★
()

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

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

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

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

helios ★★★★★
()
Ответ на: комментарий от helios

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

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

anykey_mlya
() автор топика
Ответ на: комментарий от anykey_mlya

возможен такой вариант, для 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

Sylvia ★★★★★
()
Ответ на: комментарий от Sylvia

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 работают отлично.

Sylvia ★★★★★
()
Ответ на: Why so serious? от Camel

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

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

eval-apply
()
Ответ на: комментарий от eval-apply

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

helios ★★★★★
()
Ответ на: комментарий от Sylvia

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

anykey_mlya
() автор топика
Ответ на: комментарий от anykey_mlya

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

Sylvia ★★★★★
()
Ответ на: комментарий от Sylvia

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

Sylvia ★★★★★
()
Ответ на: комментарий от Sylvia

>php-fpm

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

Rost ★★★★★
()
Ответ на: комментарий от Sylvia

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

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 порт, но это тоже вариант.

Sylvia ★★★★★
()
13 января 2011 г.

Поделюсь своим опытом, хоть и оффтоп, но возможно будет полезно. Имеется 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, не один я на эту проблему натыкался), потребление памяти несколько уменьшилось (не смогу точно сказать, насколько), ну и посты с большим количеством ббкодов стали парситься явно быстрее.

Balthazar
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.