netwind

Рейтинг
419
Регистрация
06.05.2007

Очередная разбивка диска по канонам. На ровном месте проблемы себе создали.

bums:
6666, я так понимаю речь о session.gc_maxlifetime? Чем меньше это значение, тем чаще серверу придется "прибираться" удаляя старые сессии и создавать новые, имхо это копеечная нагрузка.

да нет, в phpbb свой механизм хранения сессий в таблице.

А попробуй изменить и узнаешь.

Вопрос поиска баланса между двумя противоположностями разве может быть простой?

Чем больше больше время жизни сессии, тем больше хранится записей в таблице сессий и, как следствие, некоторые запросы вынуждены обрабатывать больше данных.

Если время жизни маленькое, то чаще запускается процедура создания сессии и связанные с ней манипуляции. Ну и если пользователь не ставит галочку "запомнить", то ему придется вводить логин постоянно и это тоже нагрузка.

Все же, мне кажется, первый эффект более важно исключить для посещаемого форума. Лучше оставить время 900 секунд как в другом популярном движке.

bsyomov:
временная таблица будет всегда создаваться на диске

МОЖЕТ создаваться при этих условиях, а не ВСЕГДА будет. по крайней мере первое условие в лоб не выполняется.

Shi3A:
И раз уж пошла такая пьянка, не подскажите, как мне сократить число Temporary tables created on disk? И что порекомендуете? Все же оптимизировать запросы под кеш, или насиловать диски?

С точки зрения чистого администратора, лучше /tmp перенести в tmpfs и уменьшить негативные эффекты от создания файлов.

Полностью избавиться только анализом и модификацией запросов, что не всегда разумно, а для CMS использующих ORM иногда и невозможно. Зачастую увеличение tmp_table_size не влияет на создание временного файла.

Я бы в вашей конфигурации попробовал бы остальные буферы уменьшить, но за их счет увеличить innodb_buffer_pool.

Shi3A:
если отключить - как может помочь?

А почему не может?

Связана или нет проблема с кешем может подтвердить профилирование запросов, но попробовать проще.

для начала уменьши или выключи совсем :

query_cache_size = 4096M

Действительно ли нужно логи доступа в базе хранить? Они ведь непропорционально много фактов генерируют. Для многих CMS со встроенными логами доступа обычно советуют их отключить, а анализ посещаемости выполнять традиционными логоанализаторами из файлов access.log.

Ну и, конечно, нужно проанализировать эти самые запросы. Без этого шага будешь еще неделю крутить ручки вслепую.

KeyCAPTCHA, я, конечно, в курсе, что типичный москвич обязательно имеет айфон, но напомню, что html5 все еще не работает на всех мобильных устройствах.

Что там с j2me-версиями opera mini ? работает?

betam:
На этом же ип кучка других сайтов, которым 443 порт отключать не надо, более того, им надо не отключать.

Что-то вы наврали. Технологически, на этом IP может быть только один https-сайт.

Такой уж протокол https. Как ни настраивай сервер, работать не будут все сайты.

Не смущает, что в memcached нет авторизации? любой клиент запишет в этот memcached что угодно и нарушит работу вашего сайта. Пожалуй, по этой причине такие хостинги и редко встречаются.

Всего: 6293