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

Drupal на общей папке NFS имеет ужасную производительность

У нас есть установка, в которой сайт Drupal 7 со следующей настройкой - хост-сервер VMware ESXi 4.1, на котором запущена веб-виртуальная машина и виртуальная машина NFS. Веб-виртуальная машина использует Apache и mod_php. Сайт все еще находится в разработке, поэтому мы должны отключить все формы кеширования из-за часто обновляемых файлов.

Выполнение каждого запроса страницы занимает около 15-20 секунд. Профилирование кода PHP показывает, что подавляющее большинство времени (обычно более 90%) занимают все вызовы функций is_dir (), is_file (), которые загружают модули.

Я увеличил размер кеша realpath PHP до нескольких мегабайт, и strace показывает, что количество вызовов lstat затем падает с 200 до 6, а stat () немного уменьшается (около 600 вызовов). Однако, несмотря на то, что это сэкономило довольно много времени, я просто не могу преодолеть 10-секундный барьер на запрос для самой требовательной страницы.

Есть ли способ повысить производительность этой настройки без кеширования?

Изменить: проблема не в MySQL, кеширование запросов означает, что выполнение запросов занимает не более секунды.

Конфиги и статистика:

Хост ВМ: один четырехъядерный процессор Xeon

ВМ:

web - Centos 6 64bt, 2,5 ГБ ОЗУ, нормальный приоритет CPU / HD (2 ядра) nfs - Centos 6 64bt, 2 ГБ RAM, нормальный приоритет процессора (4 ядра), высокий приоритет HD

PHP: размер кэша realpath 32M (это значение для целей тестирования)

NFS:

~]# egrep -v '#|^$' /etc/nfsmount.conf 
[ NFSMount_Global_Options ]
 Defaultvers=4
 Ac=False
 Rsize=32k
 Wsize=32k
 Bsize=32k

Скорость чтения через NFS не является проблемой, dd 100-мегабайтного тестового файла с использованием 32-килобайтных блоков возвращает:

3200+0 records in
3200+0 records out
104857600 bytes (105 MB) copied, 1.84984 s, 56.7 MB/s

real    0m1.857s
user    0m0.007s
sys 0m0.330s 

Strace в процессе Apache с пустым кешем realpath:

    % time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 50.78    1.157452         337      3434        28 stat
 32.58    0.742656         628      1182       425 open
  9.29    0.211788         762       278         1 lstat
  3.17    0.072322           0    237865           write
  2.45    0.055839         490       114        13 access
  0.45    0.010262          43       237           brk
  0.34    0.007725          10       811        74 read
  0.28    0.006340           9       679           fstat
  0.22    0.005069          18       281           poll
  0.20    0.004533           6       698           getdents
  0.09    0.001960          10       190           mmap
  0.05    0.001065          14        74           accept4
  0.04    0.001000         333         3           chdir
  0.03    0.000750           4       190           munmap
  0.01    0.000339           0       836           close
  0.01    0.000247           3        75           writev
  0.00    0.000068           0       611           fcntl
  0.00    0.000063           1        77           shutdown
  0.00    0.000000           0         1           lseek
  0.00    0.000000           0         5           rt_sigaction
  0.00    0.000000           0         1           rt_sigprocmask
  0.00    0.000000           0         3           setitimer
  0.00    0.000000           0         5           socket
  0.00    0.000000           0         5         5 connect
  0.00    0.000000           0        74           getsockname
  0.00    0.000000           0        15           setsockopt
  0.00    0.000000           0         5           getcwd
  0.00    0.000000           0         1           futex
------ ----------- ----------- --------- --------- ----------------

Strace после кеширования реальных путей

    % time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 60.14    1.371006         484      2831        28 stat
 31.79    0.724705         627      1155       425 open
  3.53    0.080354           0    237865           write
  2.65    0.060433         530       114        13 access
  0.43    0.009913          99       100           brk
  0.38    0.008730          11       804        74 read
  0.35    0.007910          12       675           fstat
  0.30    0.006775          10       654           getdents
  0.13    0.003065          11       281           poll
  0.09    0.002000         333         6         1 lstat
  0.07    0.001545           2       807           close
  0.05    0.001063          14        74           accept4
  0.04    0.001000           6       179           mmap
  0.02    0.000404           2       179           munmap
  0.01    0.000271           4        75           writev
  0.01    0.000212           0       611           fcntl
  0.01    0.000129           2        77           shutdown
  0.00    0.000022           0        74           getsockname
  0.00    0.000000           0         1           lseek
  0.00    0.000000           0         5           rt_sigaction
  0.00    0.000000           0         1           rt_sigprocmask
  0.00    0.000000           0         3           setitimer
  0.00    0.000000           0         3           socket
  0.00    0.000000           0         3         3 connect
  0.00    0.000000           0        15           setsockopt
  0.00    0.000000           0         5           getcwd
  0.00    0.000000           0         3           chdir
------ ----------- ----------- --------- --------- ----------------

Крепление:

nfs.xxx.xxx.xxx:/path/to/website/files on /path/to/website/files type nfs (rw,hard,intr,noac,vers=4,addr=xx.xx.xx.xx,clientaddr=xx.xx.xx.xx)

Любая помощь, естественно, приветствуется.

Откровенно говоря, Drupal на NFS - настоящая свинья. В лучшем случае вы хотите предоставить общий доступ к каталогу "files" {y, ies} через NFS или что-то вроде gluster. Проблема с запуском DocRoot на NFS заключается в том, что в сумме все вызовы lstat (2) и access (2) являются убийственными, не говоря уже о getdent (2) и друзьях, которых вы увидите в каталогах модулей. Что-то вроде APC значительно поможет фактическому чтению (2) раза, а также устранению задержек компиляции, но PHP по-прежнему будет выполнять lstat (2) и доступ (2) для каждого файла. Чтобы еще больше ускорить процесс, вы можете установить apc.stat = 0, но это не поможет вам, если, как вы сказали, вы постоянно меняете файлы PHP, если только вы не хотите перезапустить Apache (или вручную очистить APC cache через apc.php) каждый раз, когда вы вносите такое изменение.

Лучшие практики рекомендуют хранить DocRoot либо на выделенном, оптимизированном устройстве (например, SAN), либо отдельно на каждой веб-головке. Каталог «files» обычно должен использоваться через gluster / nfs / и т. Д., Но в качестве альтернативы вы также можете периодически синхронизировать его между серверами, в зависимости от варианта использования и от того, поддерживает ли передний LB липкие сеансы. Вы также можете полностью удалить каталог файлов, используя CDN или сервис, такой как S3 от Amazon или Swift от BlackMesh.

Хостинг-провайдер с подробным специализированным знанием Drupal может помочь вам с некоторыми из этих архитектурных проблем; вы можете связаться с Acquia или BlackMesh (я работаю в последнем). Я не знаю, делает ли Acquia, но я знаю, что BlackMesh также предлагает внешнюю помощь, когда мы работаем с вашим существующим хостинг-провайдером или на месте, чтобы оптимизировать решение для Drupal.

Удачи с вашим сайтом!

Монтаж с noac вообще убийца производительности.

Почему ты им пользуешься?

РЕДАКТИРОВАТЬ: я вижу выше в комментарии, в котором вы говорите, что позже добавляете больше веб-серверов и балансировщик нагрузки. Как предложил BMDan, вам следует изучить файловую систему кластера (например, OCFS2), если ваше приложение требует, чтобы вы использовали noac.

Ура