Drupal 7 + nginx = 504 gateway time-out

Цель: Drupal 7 при обновлении локализации модулей падает в 504 страницу, в логах же что то типа вот этого:

*1790 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 192.168.128.94, server: flowers64.loc, request: "POST /batch?id=12&op=do HTTP/1.1", upstream: "fastcgi://unix:/var/run/www.socket:", host: "flowers64.loc", referrer: "http://flowers64.loc/batch?op=start&id=12"

Дано: Drupal 7,  nginx/0.7.67, php-fpm 5.3.8, mysql (14.14 Distrib 5.1.58)

Решение:
Оказалось, Drupal 7, вражина эдакая при установки с нуля и при наличии такой возможности использует InnoDB для своих таблиц в БД. Тут та и был зарыт подводный камень для относительно стареньких машинок. Данные InnoDB хранятся в больших совместно используемых файлах, и при интенсивных вставках в ваши таблицах, на относительно слабых машинках жутко будет тормозить ...


Одним словом если вам досталась такая досада, то решается она просто, лезим в конфиги mysql сервера и читаем, cat /etc/mysql/my.cmf

# If set to 1, InnoDB will flush (fsync) the transaction logs to the# disk at each commit, which offers full ACID behavior. If you are# willing to compromise this safety, and you are running small# transactions, you may set this to 0 or 2 to reduce disk I/O to the# logs. Value 0 means that the log is only written to the log file and# the log file flushed to disk approximately once per second. Value 2# means the log is written to the log file at each commit, but the log# file is only flushed to disk approximately once per second.innodb_flush_log_at_trx_commit=1

В моем случае, по умолчанию данный параметр равен 1 ... (времени убито много на выискивание сия засады) ... правим, перебиваем на 0 или 2 и перепроверяем работу движка и его скриптов в которых собственно он и подстыкался.


Примечание: вообщем, хоть и камень был устранен, БД была переведена на MyISAM.