Назад | Перейти на главную страницу

Moodle с 10 потоками медленно работает на lighttpd

Я запустил Moodle на Lighttpd на Centos 6 с 1 ГБ оперативной памяти. Если я открою 10 потоков для moodle, то Moodle начнет работать очень медленно.

Как я могу ускорить сервер? Мне нужно обслуживать множество пользователей.

Я проверил память с помощью свободной команды, и у меня много свободной памяти.

РЕДАКТИРОВАТЬ: я вижу высокий процессор php-cgi.

верхняя:

# top -b -n 1 | head -30
top - 08:55:32 up 24 days, 21:37,  2 users,  load average: 0.70, 0.24,
 0.08
Tasks: 153 total,   2 running, 151 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.2%us,  0.3%sy,  0.0%ni, 99.4%id,  0.0%wa,  0.0%hi,  0.0%si,
0.1%st
Mem:   1016480k total,   828692k used,   187788k free,   151316k buffers
Swap:   999992k total,     4036k used,   995956k free,   426880k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
29247 lighttpd  20   0  477m 103m  61m R 92.1 10.4   1:37.25 php-cgi
23947 root      20   0 15020 1188  864 R  3.6  0.1   0:00.03 top
    1 root      20   0 19228 1040  860 S  0.0  0.1   0:00.61 init
    2 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kthreadd
    3 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 migration/0
    4 root      20   0     0    0    0 S  0.0  0.0   0:05.49 ksoftirqd/0
    5 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 migration/0
    6 root      RT   0     0    0    0 S  0.0  0.0   0:08.99 watchdog/0
    7 root      20   0     0    0    0 S  0.0  0.0   4:35.86 events/0
    8 root      20   0     0    0    0 S  0.0  0.0   0:00.00 cgroup
    9 root      20   0     0    0    0 S  0.0  0.0   0:00.00 khelper
   10 root      20   0     0    0    0 S  0.0  0.0   0:00.00 netns
   11 root      20   0     0    0    0 S  0.0  0.0   0:00.00 async/mgr
   12 root      20   0     0    0    0 S  0.0  0.0   0:00.00 pm
   13 root      20   0     0    0    0 S  0.0  0.0   0:00.00 xenwatch
   14 root      20   0     0    0    0 S  0.0  0.0   6:02.87 xenbus
   15 root      20   0     0    0    0 S  0.0  0.0   0:21.59 sync_supers
   16 root      20   0     0    0    0 S  0.0  0.0   0:18.66 bdi-default
   17 root      20   0     0    0    0 S  0.0  0.0   0:00.00
kintegrityd/0
   18 root      20   0     0    0    0 S  0.0  0.0   0:13.23 kblockd/0
   19 root      20   0     0    0    0 S  0.0  0.0   0:00.00 ata/0
   20 root      20   0     0    0    0 S  0.0  0.0   0:00.00 ata_aux
   21 root      20   0     0    0    0 S  0.0  0.0   0:00.00
ksuspend_usbd

свободно:

# free -m
         total       used       free     shared    buffers     cached
Mem:           992        809        183          0        147        416
-/+ buffers/cache:        244        748
Swap:          976          3        972

cat / proc / cpuinfo:

processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 16
model               : 4
model name  : Quad-Core AMD Opteron(tm) Processor 2374 HE
stepping    : 2
cpu MHz             : 2200.130
cache size  : 512 KB
fpu         : yes
fpu_exception       : yes
cpuid level : 5
wp          : yes
flags               : fpu de tsc msr pae cx8 cmov pat clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext
3dnow up rep_good unfair_spinlock pni cx16 popcnt hypervisor lahf_lm cmp_legacy extapic cr8_legacy abm sse4a misalignsse
3dnowprefetch
bogomips    : 4400.26
TLB size    : 1024 4K pages
clflush size        : 64
cache_alignment     : 64
address sizes       : 48 bits physical, 48 bits virtual
power management:

Пока ваш единственный поток php-cgi высок, системная нагрузка невысока; Вы подключаете только одно из ядер вашего процессора. Кажется, что вашему ящику достаточно места для роста, вам просто нужно настроить конфигурацию Lighttpd и PHP-CGI, чтобы получить нужный масштаб.

Первоначальная проблема заключается в том, что вы отправляете весь запрос в один поток php-cgi. Итак, вы используете остальные 3 ядра вашего бокса. Вместо использования php-cgi я бы предложил запустить PHP-FPM, который будет прослушивать единственный сокет или порт; и будет балансировать нагрузку запроса на количество рабочих потоков, которые вы определяете. Если этот блок также выполняет MySQL или другие задачи, вы можете захотеть только масштабировать его, чтобы оставить одно ядро ​​пустым для других нужд обработки.

Еще одна вещь, на которую следует обратить внимание, - это то, что вы на самом деле тестируете. Когда вы говорите 10 потоков - о чем вы на самом деле говорите. Когда я использую 10 потоков, я предполагаю, что у вас есть 10 процессов, которые делают столько вызовов на сервер, сколько они могут (JMeter). Это может привести к 10 запросам в секунду или 50 запросам в секунду. Другой вопрос: каждый поток также загружает все ресурсы в html-запросе или это просто HTML.

В Google есть много руководств по настройке PHP-FPM и Lighttpd, вот краткое из них, которое я извлек из верхней части поиска Google - http://www.howtoforge.com/installing-lighttpd-with-php5-php-fpm-and-mysql-support-on-ubuntu-12.04

Основываясь на том, что я вижу; вы сможете увеличить количество подключений в 3-4 раза, как только вы настроите Lighttpd и PHP на использование всех ваших ядер.

Использование ЦП для php-cgi довольно велико. Медлительность вашего сервера обычно может быть связана с двумя факторами: процессором или вводом-выводом.

Операции ввода-вывода (если мешают) видны через индикатор% wa (ожидание) и могут быть вызваны нехваткой памяти и свопингом (который помещает память на диск, а затем все замедляет). Как правило, это хорошая идея для веб-серверов, где стабильность не является абсолютно критичной (как в случае обычно с веб-страницами: если это не сработает, просто обновите), чтобы полностью удалить своп с помощью команды (от имени пользователя root)

swapoff -a

Если у вас высокая загрузка ЦП и он исходит из PHP, но% wa низкий, тогда вы определенно сталкиваетесь с проблемой производительности, связанной с выполнением кода PHP (например, из-за противодействия запросам SQL). Лучший способ избежать этого - попробовать использовать кеширование кода операции (например, APC или кеш кода операции Zend, который поставляется с PHP 5.5). Кэш опкодов эффективно использует небольшой объем памяти, но позволяет избежать большого объема вычислений (он помещает предварительно скомпилированные версии ваших PHP-скриптов в память, поэтому загрузка их дважды - или десять раз - «вычисляет» их только один раз).

При этом Moodle - не лучшая LMS, если вы хотите запустить ее на «сервере» с низким ЦП и малым объемом памяти.