drupal со всеми что есть поисклвыми скриптами -- нехилая нагрузка.
исходя только из того, что я вижу "снаружи", -- проблема будет в нагрузке на DB.
Путей решения можно напридумывать много, но от красивостей a la drupal на настоящих нагрузках придёися отказаться.
"Жрёть много..." :)

Я прекрасно понимаю, что если сгенерить толпу статичных html-ей, то нагрузка упадёт в сотни раз.
Так что отказ от красивостей - путь очевидный. Но он мне не нравится.
Есть какой-либо дешевый способ отсеивать роботов и подсовывать им некрасивый вариант?

А есть уверенность, что данное решение вообще способно работать под нагрузкой?

Есть уверенность, что не может. То есть уже не работает.
По-началу сервер периодически зависал напрочь, сейчас сунул в крон скрипт, который при превышении loadaverage уровня 10 тупо на минуту гасит апач. Помогло, но это как-то не то.
Отсюда и вопрос - что переделывать.
По опыту знаю, что в одном месте добавив пару строк можно снизить нагрузку втрое, а в другом провозившись неделю - выиграть 3%.
Только опыт мой далёк от веб-девелопмента. Трудно найти правильное место.
Хочется совета опытных товарищей.

Кто отжирает проц? Мускуль?

top - 10:17:56 up 8 days, 8 min, 5 users, load average: 0.52, 0.81, 1.17
Tasks: 131 total, 1 running, 130 sleeping, 0 stopped, 0 zombie
Cpu(s): 12.7%us, 1.0%sy, 0.0%ni, 85.7%id, 0.3%wa, 0.0%hi, 0.3%si, 0.0%st
Mem: 1024608k total, 861044k used, 163564k free, 17016k buffers
Swap: 1028120k total, 422552k used, 605568k free, 367356k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3038 apache 20 0 43792 21m 4352 S 11.0 2.2 0:31.22 httpd
2417 mysql 20 0 206m 42m 3176 S 1.7 4.3 780:15.00 mysqld
5410 root 20 0 8184 1356 1132 S 0.3 0.1 0:04.60 sshd
16464 apache 20 0 43744 22m 4336 S 0.3 2.2 0:12.74 httpd
20722 apache 20 0 10736 5744 2552 S 3.3 0.6 0:00.10 2.pl
16091 apache 20 0 43700 21m 3800 S 1.0 2.1 0:09.67 httpd
14487 apache 20 0 43548 21m 4404 S 0.7 2.2 0:02.29 httpd
14787 apache 20 0 43760 22m 4480 S 0.7 2.2 0:11.59 httpd
20716 apache 20 0 10740 5744 2552 S 0.7 0.6 0:00.10 2.pl
2181 root 20 0 12700 504 384 S 0.3 0.0 3:19.49 pcscd
1 root 20 0 2044 424 400 S 0.0 0.0 0:05.73 init
2 root 15 -5 0 0 0 S 0.0 0.0 0:00.05 kthreadd
3 root RT -5 0 0 0 S 0.0 0.0 0:00.00 migration/0
4 root 15 -5 0 0 0 S 0.0 0.0 0:00.61 ksoftirqd/0
5 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/0
6 root 15 -5 0 0 0 S 0.0 0.0 0:04.26 events/0
7 root 15 -5 0 0 0 S 0.0 0.0 0:00.09 khelper
46 root 15 -5 0 0 0 S 0.0 0.0 7:18.82 kblockd/0
47 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 kacpid
48 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 kacpi_notify
146 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 cqueue/0
147 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 ksuspend_usbd
150 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 khubd
152 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 kseriod
163 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 khpsbpkt
178 root 15 -5 0 0 0 S 0.0 0.0 19:12.75 kswapd0
229 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 aio/0
392 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 kpsmoused
418 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 ata/0
419 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 ata_aux
422 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 scsi_eh_0
423 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 scsi_eh_1
424 root 15 -5 0 0 0 S 0.0 0.0 0:53.27 kjournald
451 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 kauditd
485 root 16 -4 2128 292 292 S 0.0 0.0 0:00.25 udevd
777 root 20 0 8048 1128 1032 S 0.0 0.1 0:00.63 sshd
784 root 20 0 4280 584 584 S 0.0 0.1 0:00.01 sftp-server
1582 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 kmpathd/0
1620 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 kjournald
1621 root 15 -5 0 0 0 S 0.0 0.0 1:12.63 kjournald
1622 root 15 -5 0 0 0 S 0.0 0.0 0:58.12 kjournald
2026 root 20 0 1708 472 428 S 0.0 0.0 0:04.05 syslogd
2029 root 20 0 1656 304 304 S 0.0 0.0 0:00.03 klogd
2130 root 20 0 4952 264 236 S 0.0 0.0 0:03.04 rpc.idmapd
2158 dbus 20 0 2724 268 268 S 0.0 0.0 0:00.00 dbus-daemon
2210 root 20 0 1892 316 316 S 0.0 0.0 0:00.00 hidd
2232 root 20 0 7308 672 568 S 0.0 0.1 0:13.49 automount
2255 root 20 0 1656 360 360 S 0.0 0.0 0:00.00 acpid
2281 root 20 0 5196 444 444 S 0.0 0.0 0:01.81 sshd
2297 root 20 0 2684 424 424 S 0.0 0.0 0:00.00 xinetd
2314 root 20 0 4608 180 180 S 0.0 0.0 0:00.07 vsftpd
2381 root 20 0 4496 388 388 S 0.0 0.0 0:00.01 mysqld_safe

судя по всему — это пхп с друпалом выёживаюццо. попробуй таки сменить сервер (который http %-). пересобрать пыхпых/mod_пыхпых с -O3 и под твою архитектуру тоже не помешает, если ты юзаешь бинарный пакет.

Ну, весьма предварительное имхо - проц-то и не грузится. Зато некоторая фигня развалилась в свопе и давай там валяться. Что характерно, ее не видно - и цифирь отжираемой памяти у всего обозримого вполне в пределах, и процессов засвопленных не видать. Но весьма вероятно, что тормоза именно из-за того, что это нечто периодически начинает из свопа - в своп гулять почем зря. Я бы (опять-таки исключительно в плане аборта по телефону) заподозрил бы утечки памяти э-э-э.., ну, скажем, у апача. И написал бы ему за это что-то типа
MaxRequestsPerChild 10
От этого апачевы дети, отработав указанное количество запросов, будут умирать, и так им и надо.

loadaverage за последние несколько часов:
Fri Oct 19 06:00:02 PDT 2007 1.31 2.92 11.79 1/166 16016
Fri Oct 19 06:10:01 PDT 2007 0.46 0.87 6.45 1/169 17060
Fri Oct 19 06:20:01 PDT 2007 1.90 1.31 3.97 2/164 18421
Fri Oct 19 06:30:02 PDT 2007 3.52 3.39 3.62 1/181 20095
Fri Oct 19 06:40:01 PDT 2007 2.02 2.56 2.98 1/174 21470
Fri Oct 19 06:50:02 PDT 2007 1.34 1.33 2.12 7/181 22890
Fri Oct 19 07:00:02 PDT 2007 0.82 0.97 1.60 1/163 24199
Fri Oct 19 07:10:02 PDT 2007 0.84 1.04 1.38 2/167 25651
Fri Oct 19 07:20:02 PDT 2007 1.16 1.15 1.22 4/181 26964
Fri Oct 19 07:30:01 PDT 2007 0.85 1.10 1.17 1/170 28433
Fri Oct 19 07:40:02 PDT 2007 2.33 1.62 1.28 1/180 29817
Fri Oct 19 07:50:01 PDT 2007 2.20 1.80 1.49 1/177 31468
Fri Oct 19 08:00:02 PDT 2007 2.24 2.07 1.65 2/178 710
Fri Oct 19 08:10:01 PDT 2007 0.85 1.09 1.35 7/170 2462
Fri Oct 19 08:20:01 PDT 2007 1.07 0.97 1.13 2/170 4056
Fri Oct 19 08:30:02 PDT 2007 1.20 1.62 1.54 3/175 5513
Fri Oct 19 08:40:01 PDT 2007 1.34 1.60 1.53 1/179 7149
Fri Oct 19 08:50:01 PDT 2007 0.56 1.08 1.30 1/168 8597
Fri Oct 19 09:00:01 PDT 2007 4.31 3.41 2.18 1/181 10350
Fri Oct 19 09:10:01 PDT 2007 0.94 1.14 1.52 2/163 11475
Fri Oct 19 09:20:01 PDT 2007 0.79 0.78 1.12 2/150 12415
Fri Oct 19 09:30:01 PDT 2007 0.56 0.68 0.89 2/151 13514
Fri Oct 19 09:40:02 PDT 2007 0.62 0.64 0.76 1/162 14386
Fri Oct 19 09:50:02 PDT 2007 2.83 1.75 1.15 1/165 15737
Fri Oct 19 10:00:03 PDT 2007 1.59 1.81 1.58 3/188 17874
Fri Oct 19 10:10:01 PDT 2007 0.70 1.36 1.52 1/149 19875
Fri Oct 19 10:20:01 PDT 2007 0.57 0.70 1.08 1/146 20907
Fri Oct 19 10:30:01 PDT 2007 0.76 0.94 0.97 3/197 22426
Fri Oct 19 10:40:02 PDT 2007 2.40 2.01 1.53 3/187 25061
Fri Oct 19 10:50:02 PDT 2007 5.25 3.59 2.38 4/197 27916
Fri Oct 19 11:00:01 PDT 2007 1.38 2.25 2.27 1/189 30607
Fri Oct 19 11:10:02 PDT 2007 4.54 3.25 2.75 1/210 529
Fri Oct 19 11:20:01 PDT 2007 2.43 2.41 2.56 3/184 3448
Fri Oct 19 11:30:01 PDT 2007 3.87 4.26 3.36 1/198 5913
Fri Oct 19 11:40:01 PDT 2007 1.72 2.31 2.74 3/187 8633
Fri Oct 19 11:50:02 PDT 2007 2.99 2.53 2.59 1/188 11402
Fri Oct 19 12:00:01 PDT 2007 1.47 1.57 1.99 1/163 13212
Fri Oct 19 12:10:01 PDT 2007 1.62 1.56 1.81 1/176 15732
Fri Oct 19 12:20:01 PDT 2007 0.55 1.37 1.67 3/159 18080
Fri Oct 19 12:30:01 PDT 2007 0.73 0.88 1.28 3/146 19326

Или это к загрузке процессора не относится?

Стояло 4000. Это много?
Поменял. Посмотрим, что получится.

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

уменьшился
top - 13:34:00 up 8 days, 3:24, 2 users, load average: 0.80, 1.71, 1.50
Tasks: 142 total, 2 running, 140 sleeping, 0 stopped, 0 zombie
Cpu(s): 11.0%us, 1.0%sy, 0.0%ni, 85.7%id, 2.0%wa, 0.0%hi, 0.3%si, 0.0%st
Mem: 1024608k total, 918860k used, 105748k free, 7396k buffers
Swap: 1028120k total, 89880k used, 938240k free, 311424k cached

Уже достижение:)
Хотя вроде на загрузке не особо сказалось... Посмотрим, будут ли скачки - логи, я так понимаю, ведутся.

Логи ведутся - http://lib.rus.ec/cpu.log
Нагрузка нестабильна - пришел бот и всё сожрал.
Посмотрим хотя-бы пару дней, будет понятно.

настройки апача и мускуля по умолчанию - зло
там есть много чего поковырять

проще всего ввести какое-угодно кэштрование
от простого кэширования в PHP (тут советую APC)

до какой-то схемы отдачи статичного хтмл для большинства страниц

Друпал конечно тоже зло

Кэширование в друпале есть встроенное. Не знаю, насколько эффективное.
Буду изучать APC.

чисто субъективно (лом мерять, но глазом видно) — lighttpd шустрее апачи. ну и — убить друпал, как уже говорили. или хотя бы зендоптимайзером его.

ещё можно купить платный мускуль — камрады глаголют, он шустрее халявного.

ИМХА ощущаеть, что это не есть решение. Но это только ИМХА.

не полное. но сменить апач и друпл надо однозначно. %-)

На что менять друпал?
С сохранением функциональности, очевидно.
От движка нужны: регистрация пользователей, блоги/форумы, общее построение сата (блоки) - собственно, как оно есть.
Делать хуже не хочется.

Насколько сложно установить lighthttpd? Оно умеет mod_rewrite или аналог?

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

lighttpd (я не опечатался %-) прост, как топором по тыкве. подправить дефолтный конфиг (он небольшой и скаментами), да запустить. у меня переход с апача занял примерно 10 минут (это у меня висит рабочая e107 + личные скрипты на Lua). правда, нужно, чтобы пыхпых умел fastcgi (не все сборки умеют; возможно, придёццо пересобрать ручками). в режиме «просто cgi» у меня пыхпых бабах, но оно и не стоит — неэффективно.

аналог rewrite есть, даже правила (если простые) переносятся без особой головной боли.

Платные решения в пиратской библиотеке не рассматриваются по религиозным соображениям.

ну, можно ж и не покупать… %-)

Я не сказал купленные.
Я сказал платные.
Тут есть небольшой ньюансик.
От того, что ты не заплатил, оно не перестало быть платным.
Хотелось бы по-возможности этого избегать.

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

это я протупил. для меня спёртое автоматически превращаеццо в бесплатное/свободное. %-)

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

траблы не с мускулом.
траблы с головой.
у мускула был выключен кэш.
Т.е. кеш включен, а памяти под него выделено - 0.
Выделил побольше и сразу стало заметно лучше.

quote:у мускула был выключен кэш.промеждупрочим… полез проверять свои конфиги

SHOW STATUS LIKE 'Qcache%';
всё видно.

ну, так я и знал. (ц) всё по нулям… ты не один. %-)

tnx.

:)
А ты говоришь - апач, друпал...
SET GLOBAL query_cache_size=50000000; - и всё летает.
Такие дела.

не, это ты загнул, конечно. столько я ей не дам — я ж на этой машине ещё и работаю! а вот метро 10, положим, дам. %-)

зыж tnx за команду. а то я со своей эльфийской неторопливостью лет 5 уговаривал бы себя доки почитать. %-)

не за что.
(гордо) я её сам придумал, без доков!
сначала говорю set - а мускул мне в ответ - юзай global.

вах. мне оно тоже что-то пояснить пыталось, но у меня моск ушиблен правкой кривучего php…

Спасибо :) Случайно забрёл к вам в старые посты, а у меня оказывается тоже кэш выключен :)))

>ну, можно ж и не покупать… %-)
Низ-зя! ;) Сказано ж было: по религиозным, а не по финансовым! :)

ты меня понял!

это я протупил. для меня спёртое автоматически превращаеццо в бесплатное/свободное. %-)

Постучитесь в jabber alexkuklin@irrc.ru или по телефону +7 962 9344096 - пообщаемся.

Сейчас совершенно нерабочее состояние.
В двух словах - апач менять на nginx, mod_php на php-fcgi, движок - на другой.

Подробности - лично. :)

Как-то крутовато.
Особенно замена движка меня не радует.
Проще второй сервер прикупить:)

Кто-то только что говорил, что "это не наш путь" :)

Вообще, первые два пункта, как правило, проходят достаточно гладко.
Можно посмотреть, вдруг будет достаточно только frontend поставить?

Не наш. Но менять Друпал - ещё менее наш. Вот кэш где включить - наш, минимум усилий с максимум эффекта.
Не думаю, что другая CMS со схожим функционалом будет принципиально лучше.
Вон, зеебук лежит постоянно без всякого друпала.

Кто такой frontend и как его ставить?
Система - федора/i386, инсталятор yum.

Видимо фронтенд это отдавать статичные файлы (т.е. книги и картинки) не через апач, а через nginx.

Такое разделение действительно помогает при нагрузке.

query_cache - это только начало :)
Выбрось сюда неконфиденциальную часть твоего my.cnf - на месте и починим.

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
# Default to using old password format for compatibility with mysql 3.x
# clients (those using the mysqlclient10 compatibility package).
old_passwords=1
set-variable=long_query_time=1
log-slow-queries=/var/log/mysql-slow-queries.log
query_cache_size = 55M

[mysql.server]
user=mysql
basedir=/var/lib

[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid


Это, собственно, он весь.
А что там может быть конфиденциального?

Да в общем ничего особо конфиденциального там нет, кроме вещей типа old_passwords = 1, [mysql.server]user, директории, и.т.д. Однако, это мелочи. Теперь по делу:

Как я понимаю, у тебя 1Г меморей, 1 процессор, и твой милый друг друпал использует MyISAM формат для таблиц (если в чем ошибся, укажи please).
В этом случае:

-----

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
# Default to using old password format for compatibility with mysql 3.x
# clients (those using the mysqlclient10 compatibility package).
old_passwords=1
set-variable=long_query_time=2
log-slow-queries=/var/log/mysql-slow-queries.log
query_cache_size = 55M

skip-locking
key_buffer = 256M
max_allowed_packet = 1M
table_cache = 256
sort_buffer_size = 1M
read_buffer_size = 1M
read_rnd_buffer_size = 4M
myisam_sort_buffer_size = 64M
thread_cache_size = 8
query_cache_size= 55M
thread_concurrency = 4

[mysql.server]
user=mysql
basedir=/var/lib

[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

[mysqldump]
quick
max_allowed_packet = 16M

[mysql]
no-auto-rehash

[isamchk]
key_buffer = 128M
sort_buffer_size = 128M
read_buffer = 2M
write_buffer = 2M

[myisamchk]
key_buffer = 128M
sort_buffer_size = 128M
read_buffer = 2M
write_buffer = 2M

-----

Enjoy :)

Да, всё правильно.

Прописал, посмотрим что будет. Буферов получается почти на всю память - это так и задумано? Там же ещё апач, ngnix, php кэш...

Это либо для машинки с 512М, которая в основном MySQL сервер, либо, как в твоем случае, для машинки с 1Г, которая при этом еше и апач. Если ей станет невмоготу (в чем я сомневаюсь), переполовинь key_buffer, read_rnd_buffer_size, и myisam_sort_buffer_size. Но я думаю, не придется.

OK, спасибо.

10 дней спустя - ну как?

Работает, спасибо.
По совокупности всего тюнинига la держится меньше 0.5
Это хорошо.

key_buffer = 256M
sort_buffer_size = 128M

А можно поинтерисоваться, чем вы руководствуетесь при выборе размера для следующих дирректив?
key_buffer = 256M
myisam_sort_buffer_size = 64M
query_cache_size= 55M

И насколько оно будет полезно для innoDB?

А ты кешируешь блоки на сайте отдельно? Есть у друпала для этого модуль.

Да. Я много чего кеширую, в том числе и блоки.