В определенных условиях CMS ставит мой сервер на колени (остается 0% ЦП, в то время как загрузка сервера обычно никогда не превышает 20%, официально из mysqld, тонны ожидания и tml в mysql, медленный журнал mysql взрывается с выделением tmp и т. Д.) . Это хорошо известный случай для данной CMS, основанный на сочетании следующих событий:
Дискуссионные форумы этой CMS (называемой Piwigo) знают об этой проблеме, но единственный ответ, который дается, - «переключитесь на NginX с Php-fpm». Умножим на 100 количество изображений и посетителей, если это NginX вместо Apache + SuPHP, проблема все равно отсутствует.
Проблема в том, что я не могу переключить весь сервер на NginX одним щелчком пальцев, это касается не только моих собственных веб-сайтов и - не стыдно признаться - у меня еще нет опыта работы с NginX. Я должен поддерживать рабочие веб-сайты в рабочем состоянии, поэтому мой сервер должен продолжать использовать Apache.
Имея это в виду, пожалуйста, видите ли вы выход из этой проблемы? Какой-то способ "обмануть" и позволить suPHP снова заработать в этой конкретной ситуации? Если это происходит за счет поглощения 10+ ГБ ОЗУ, эй, конечно, почему бы и нет, мой сервер использует только треть своих 32 ГБ ОЗУ, и даже с остальными для кеширования использование диска спокойно. Если это будет за счет удвоения заряда ЦП, ха-ха, еще раз, конечно, это было бы нормально.
Если у вас есть предложения, я на самом деле весь уши!
Подробности о моем сервере: Debian Wheezy, Apache2, PHP версии 5.4.4-14 + deb7u14, Php, работающий как SuPHP (fcgid), Mysql 5.5.38 и, честно говоря, чудовищно мощный выделенный сервер, AMD Opteron 4334, быстрая оперативная память 32 ГБ , два SSD диска Raid-1 для / и два диска Raid-1 Sata для / home. Панель: webmin + virtualmin. Панель позволяет переключить виртуальный домен (= 1 сайт со своим пользователем) на Php-CGI или Mod-PHP. Конфигурация mysql не виновата (бесчисленное множество mysql-tuner, tuning-primer), уже постепенно настроенная, чтобы позволить высасывать тонны оперативной памяти и кэшировать, как будто завтра не наступит.
Если у вас есть предложения по решению, для которого не нужен NginX, я буду очень признателен! :)
Выполните поиск в Google для поиска сбоев piwigo, и вы получите несколько результатов, например: http://piwigo.org/forum/viewtopic.php?id=24748 http://piwigo.org/forum/viewtopic.php?id=22348
Так что, к сожалению, вы не одиноки с проблемами производительности piwigo. Кажется, что у piwigo есть несколько отличных вещей, но производительность / надежность, возможно, не входит в их число, по крайней мере, пока? Я собираюсь протестировать дзен-фото, медьмин и другие, потому что кажется, что piwigo не оптимизирован ни для больших фотографий, ни для просмотра или загрузки фотографий множеством пользователей. Возможно, разработчики знают об этой проблеме, и, возможно, именно поэтому нет функции, позволяющей пользователям загружать изображения, кроме как через какой-то дополнительный «плагин», называемый плагином сообщества. Но без этого плагина только администратор может загружать фотографии. Очевидно, что многие сайты захотят, чтобы пользователи могли загружать изображения, поэтому для них странно не предлагать эту функцию, встроенную в ядро piwigo, если, возможно, они не знают о проблемах с производительностью, и что она не сможет справиться с таким использованием.
Итак, мой ответ на ваш вопрос, к сожалению, заключается в том, что piwigo не является хорошим выбором для того, для чего вы привязываетесь к его использованию, кажется, он еще не готов для сайтов с множеством пользователей / просмотров или большим количеством загрузок изображений, и поскольку большинство галерей используют GD или магия изображений, все они могут страдать от одной и той же проблемы, когда дело доходит до этого, если это каким-то образом не реализовано иначе, чтобы избежать перегрузки сервера.
Если кто-то нашел хорошую замену piwigo с похожими функциями, но с более высокой производительностью, я хотел бы знать, я планирую провести некоторое исследование / тестирование для этой цели, когда у меня будет время.