У меня на DLE есть довольно беленькие пушистые сайты.
Вывод похожих новостей по-умолчанию кешируется.
Запросы на поиск в основном тоже довольно простые. Несколько условий + LIKE или MATCH. На базе в 200К записей такого рода запросы исполняются примерно на порядок дольше, чем с выборкой по id. Это значения примерно 0.001 -0.01 сек. Недавно этот вопрос детально исследовал.
Я уже молчу о том, что в нормальных условиях запросы на поиск поступают на несколько порядков реже чем запросы страниц.
Самая большая? Точно? Директива SQL_CALC_FOUND_ROWS в DLE 8.5 не используется. Есть вот проект на 8.5. Не нашел. Вместо этого используется менее эффективная и более привычная COUNT(*). При включенном кешировании используется довольно редко.
Зачем вы ссылку кинули? Я тоже поиском умею пользоваться.
А если не если? Версию с оверселом нужно грамотно проверить, а не списывать со старта все на хостера и советовать XEN. Если оверсел действительно имеет место, то нужно просто сменить хостера, если нет, то настраивать сервер и скрипты.
Вот так сразу, да? Apache настраивается под конкретные скрипты, их потребление памяти, а также требования к модулям.
Распишу что происходит у Вентилятор. Он запускает проверку на host-tracker.com. Этот сервис генерирует довольно много обращений и сразу. Обработкой запросов занимается apache2 с mpm prefork. В настройках по-умолчанию директива MaxClients неоправданно высока. Если я не ошибаюсь, она имеет значение по-умолчанию 150. При работе WP с настройками по-умолчанию процессы Apache2 кушают около 60 Мб. В оперативке таких процессов поместится 4. Учитывая что на VPS-ку может выделяться до 1024 Мб памяти это количество может быть увеличено до 16.
Поскольку в настройках указано значение в 150, буферизации запросов не происходит и Apache пытается создать столько форков, сколько нужно для обработки всех запросов. Таких процессов может быть до 150. На самом деле когда число таких процессов превышает 4-16, возникает out of memory. Память банально кончилась. Это, собственно, и происходит.
bafoed, в настройках Apache укажите, чтобы он слушал только 127.0.0.1. Вот и вся уличная магия.
Для начала:
1) установить и настроить nginx.
2) настроить apache2
Это не чушь, а вполне адекватный ответ. VPS нужно настроить.
Меньше слушайте всяких советчиков. У вас же есть root доступ по SSH.
Сама технология OpenVZ накладывает ограничения в основном на ядро. Его нельзя сменить, нельзя подгрузить какие-то модули. Также есть нюансы с работой с дисковым кешем, а также нюансы, которые связаны с использованием и выделением оперативной и своп памяти.
Для обычного веб-сервера эти ограничения несущественны. Серверное ПО будет работать ровно так как вы его настроили. Настройки по-умолчанию для конфигурацией с 256 Мб гарантированной памяти не катят. Там нужен практически ручной тюнинг и оптимизация. Примерные направления я вам обрисовал в начале сообщения.
Ну и пару слов на счет XEN-а. Пользовался я этой штукой. Дорого. Систему легче уронить в своп при неправильной настройке. Там если выделили 256 Мб ОЗУ - значит выделили 256 Мб. С настройками по-умолчанию "привет, перезагрузка" наступает довольно быстро.
Какие настройки? Настройки Apache хостер блокирует? Или настройки mod_php?
Давайте будем без "говно" и варезников. Сейчас рассматривается сам движок и ситуация с чрезмерной загрузкой сервера со стороны MySQL сервера.
В данной ситуации в первую очередь стоит анализировать какие запросы наибольше грузят MySQL сервер. Если таковые найдутся, то нужно копаться уже в коде, дописывать механизм кеширования.
Варианты с полным кешированием страниц на уровне nginx... Это даже не знаю как назвать. Самый крайний вариант. Сути проблемы это не решит.
Если вы уж заговорили о количестве новостей, то приведу немножко фактов. На генерацию страницы с полной новостью для гостей в DLE уходит два запроса. Один SELECT и один INSERT/UPDATE. Выборка SELECT происходит по id (PRIMARY INDEX). С какой скоростью она происходит даже при отключенном key_cache, думаю, вам объяснять не надо? На базе с 200К записей на это уходит около 0.0001 - 0.001 сек на слабеньком сервере. Это без учета query_cache. С кешем запросов вообще все мгновенно происходит. При довольно большом кеше запросов размер базы вообще особого значения не имеет.
tarin, и так. Вам в первую очередь нужно выявить какие запросы наибольше грузят сервер. Для этого в настройках MySQL включите логирование медленных запросов (параметр slow query log) и укажите лимит логирования в 1-2 секунды. Скорей-всего некие дополнения генерируют очень сложные запросы. Если все в этом плане гладко, то я бы занялся анализом размера кешей MySQL.
Недавно с подобной проблемой столкнулся. Проблема заключалась в стороннем модуле для генерации последних сообщений с форума. Пришлось ручками дописать систему кеширования.
Если говорить о нагрузках, то DLE в дефолтной поставке на вашей конфигурации с 1К новостей в сутки легко держит 100-200К пользователей.
В плане чистоты кода DLE действительно г..но, но движок этот работает очень быстро. На страницу уходит в среднем 2-4 простых запросов. С DLE плотно работал, знаю о чем говорю.
Потому что Петя и Дима плохо представляют себе объем работы.
sanek678, странно. По-моему пятница была вчера или это продолжение? ;)
Вы, надеюсь, представляете себе объем работ? Тут варианты с одним человеком не катят.
Варианты вроде
тоже не катят.
Решение проблем с дублями страниц. Там для com_content. Можно аналогично и для других компонент сделать. Вводится дополнительная проверка URL и редирект на нужную страницу.
Давайте подумаем. У вас есть рабочий сайт. Менять CMS-ку только из-за такой фигни не имеет смысла. Ведь наличие дублей само по себе ничего плохого не означает. Проблемы начинаются, когда эти дубли проиндексированы.
Проиндексированные дубли, к слову, можно легко отследить в том же GWT. Если их много, то можно чуть подкрутить механизм роутинга, добавить проверку и редирект по необходимости.
