Проблема с exp_security_hashes

alexo

Участник
Регистрация
28 Май 2006
Сообщения
315
Реакции
5
Привет всем

Скрипт 1.5.2 (аналогично и на 1.6.9)
Размер базы 189.2 MiB (в tar.gz ~50mb)

Самая большая таблица - exp_weblog_data 43000 записей - 168.6 MiB
Регистрация новых юзеров закрыта, сегодня даже прикрыл комменты (через капча), так как уже незнаю как бороться с этим.

В чем проблема - через определнные промежутки времени нагрузка на сервер (VPS with 2gb RAM) становится ого-го (скажет так только mysqld исползует от 5-15 GB) и приходится поднимать сервер.

Заметил, что проблема с 2мя таблицами - exp_security_hashes и exp_throttle.
в последное время просто напросто делаю TRUNCATE этих 2 таблицы, дабы не дать серверу пасть. Не проходит и 2-3 часов как в exp_security_hashes появляются от 6-10 000 записей (размер соответственно 2-3мв, да Overhead примерно такой же).

Если не стирать регулярно эти таблицы, то приходится констатировать падение сервера.

Вопрос: что сделать - как предотвратить такой наплыв ?
Не думаю, что update script-а решит проблему (покрайней мере переход другого сайта на 1.6.9 - не решил проблему). Про 2х версии данных нет - просто при переходе на 2х однозначно будут проблемы с плагинами, да и не только.

Спасибо
 
Предположу, это видимо из-за включенного троттлинга (типо антидос). Я вот им вообще не пользуюсь, для андидоса есть куда более надежные решения.
Не знаю, как в вашей локализации будет, но он вот здесь отключается: Admin ‣ Security and Privacy ‣ Throttling Preferences
 
Последнее редактирование:
в своё время отказались от экспершн енджин ввиду тормозов, а рабираться не было времени
посмотрите на Для просмотра ссылки Войди или Зарегистрируйся
может временно поставьте крон таск на каждый час? у сайта много посетителей?
 
может временно поставьте крон таск на каждый час? у сайта много посетителей?
в том то и дело, что если так пойдет, то совсем мало станет. Сайт постоянно обновляемый, и для себя я открыл такую истину, что хватит того, чтобы у сайта были проблемы несколько дней подряд, и через пару дней количесво посетителей падает на 20%.

Пот к примеру месяц назад. Все было сравнительно нормально (дело в том, что эти нагрузки на сервер не так, чтобы каждый день.) Они бывают 2-7 дней подряд, потом их нету может 10 дней, иногда даже 60 дней (с индексацией вроде не связанно). И как только пару дней подряд сайт недоступен скажем больше 2-3 часов, то не проходит и недели (иногда и меньше), чтобы количество посетителей пало на 15-20%.
К примеру месяц назад было 13-14 000, как только сайт не был доступен 3-5 часов в течении 2-3 дней, резко стало 7 000. За месяц нормально работы я достиг результата 9000-9300 посетителей.

За последные дни сайт в общей сумме был в дауне 7-8 часов - и как результат уже 5000-7000 посетителей.

---
А каком кроне идет речь - ExpressionEngine Cron или крон сервера? Не подскажешь что надо писать, чтобы каждые 2 часа сервер сделал "TRUNCATE exp_security_hashes "

спасибо
 
что то в это роде ?

Код:
0 */2 * * * TRUNCATE exp_security_hashes
 
что то в это роде ?
Почти.. ещё mysql с параметрами (-uпользователь, -pпароль {имя БД}) добавить.
Код:
0 */2 * * * /path/to/bin/mysql -h localhost -u USER -pPASSWORD -Bse 'TRUNCATE exp_security_hashes'

А вообще, костыль, конечно.
И решения с оф. форума тоже костыльные. вроде такого Для просмотра ссылки Войди или Зарегистрируйся
Может в новой версии починили?
 
сделал немного в другом виде, хотя смысл от этого не изменился

создал файл truncate.php
Код:
<?php
MYSQL_CONNECT('host','username','databasepassword');
@mysql_select_db("databasename") or die(mysql_error());

$query="TRUNCATE exp_security_hashes";

mysql_query($query);
mysql_close()
?>
и добавил такую строку в кронтаб
Код:
0 */2 * * * wget http://www.domain.com/truncate.php

с этим до разобрались. Спасибо всем.

Только вот вопрос к знатокам ЕЕ, что посоветуйте - как мне поступить дальше?
Update до 1.6.9 не помогло - в этом я удосужился. С 2х я не очень знаком (вчера попытался сделать апдейт на другом сайте, увидел сколько плагинов мне надо удалить - из за того, что нет новых версии - и стало немного не по себе) и вернул обратно (пока что). Другое дело, что я не уверен, что с переходом на 2х проблем станет меньше.

Переход на дедик сервер - тоже не вариант. Проблема же не в сервере, а в самом скрипте. (бл*** я еще с pmachine этот сайт перетаскивал).

Тогда может быть стоит думать о переходе не что-то другое (хотя трудно представить как можно переводить такую базу на что другое). Ну не забросить мне сайт ?

Спасибо еще раз
 
Решение проблемы с нагруженностью сайта на EE, любой версии, сопряжено со значительными
трудностями, и обусловлено это структурой хранения данных системы, кстати, не меняющейся
от версии к версии. Вообще, считается (неоффициальное мнение), что порог стабильности
для EE ~ 10 тыс. записей. Лично я, за послендних пару лет, все разросшиеся, требующие
масштабирования ресурсы, пересадил на новую, более чистую кодовую базу. Как варианты
какого-то временного решения (ничто так не постоянно, как временные решения...) можно
предложить следующее:
1. На фронэнд повесить внешнее кеширование для нечасто обновляемых страниц.
Если сайт в возрасте - их может быть до 70% и более. Скрипт складывает их в определенную
директорию со структурой, напоминающей структуру страниц сайта. Апач, находя их, даже не
запускает PHP-стек, отдает напрямую. ТО, что не найдено - передается для обработки на
фронтальный скрипт системы...
2. Состряпать скрипт под крон-задачник, который бы регулярно архивировал старые записи.
То-есть все они могут быть доступны по поиску или в архиве, но в основном механизме
выборки не участвуют...
3. Провести комплексную оптимизацию системы под высокую нагрузку, как выбором оптимальных
параметров настройки системы, так и модернизацией скриптов системы... возможно, изменением
логики их работы, структуры данных...
Удачи!
 
xcss, идея понятна.. А готовых решений нет? По кэшированию (с описанной схемой), как минимум?
 
Вообще, считается (неоффициальное мнение), что порог стабильности
для EE ~ 10 тыс. записей.
а после что? переходить на другой скрипт? на какой к примеру (имею ввиду того же класса)?

2. Состряпать скрипт под крон-задачник, который бы регулярно архивировал старые записи.
То-есть все они могут быть доступны по поиску или в архиве, но в основном механизме
выборки не участвуют...
честно говоря не совсем представляю что означает " архивировал старые записи". У меня к примеру информационный сайт с многими разделами. В каждом разделе до фига статей. Основной приток от поисковиков. Т.е. я не совсем представляю при "архивации" эти старые статьи также будут доступны и будут онлайн по старым урл или ... ?

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

в любом случае - при таком раскладе придется менять структура самого ЕЕ, что чревато проблемами (я так думаю)

3. Провести комплексную оптимизацию системы под высокую нагрузку, как выбором оптимальных
параметров настройки системы, так и модернизацией скриптов системы... возможно, изменением
логики их работы, структуры данных...

теоретически ДА, на самом деле на базе ЕЕ 1,5,2 такое сделать означает собрать команду и написать новый ЕЕ 3,0 ( :=_) )
Насколько это реально ? и во сколько это обойдется мне (хотя бы приблизительно) ?

1. На фронэнд повесить внешнее кеширование для нечасто обновляемых страниц.
а разве сейчас не внешнее кеширование работает (имею ввиду кеширование ЕЕ ?)

может быть в качестве альтернативы стоит и рассматривать вариант, когда на одном и том же сайте (и хосте) работают 2 скрипта под тот же сайт и те же нужды (скажем 2 ЕЕ или ЕЕ + друпал -> старый сайт + новый сайт). Я ошибаюсь или мне кажется, что при этом не будет такой же нагрузки, как скажем на одном скрипте (тут конечно могут возникнуть всякие проблемы с поиском, архивом итд, но это меньшая беда по сравнению с тем, что сайт лежит в дауне)
 
Назад
Сверху