31 января 2007 в 11:23
Господа, столкнулся с проблемой.
Скажу сразу, что обновлял ОТЛИЧНО работающую 4.7 версию Друпала до 5.0.
До обновления все работало просто замечательно, я бы даже сказал летало.
После установки пятерки сайт даже не ползает. Главная загружается около 40 секунд, а иногда и не загружается вовсе. Причем странная фишка: когда я пытаюсь зайти на главную, бегунок загрузки показывает обьем странички, замирает секунд на 30 и только потом начинает ее грузить.
На загрузки вторых страниц (нод, небольших) уходит секунд 25. Что тоже не быстро.
Из доп. модулей - только panels и views. Отключил - те же вилы. Не быстрее.
Какие будут мнения по тому отчего такая фигня? И может имеет смысл к 4.7 вернуться?
Комментарии
поставь devel, посмотри что сколько грузиться.
ооо. тут все весело.
55.49 1 cache_get SELECT data, created, headers, expire FROM cache WHERE cid = 'locale:ru'
41.82 1 path_nodeapi SELECT dst FROM url_alias WHERE src = 'node/4212'
33.64 1 node_load SELECT n.nid, n.vid, n.type, n.status, n.created, n.changed, n.comment, n.promote, n.sticky, r.timestamp AS revision_timestamp, r.title, r.body, r.teaser, r.log, r.format, u.uid, u.name, u.picture, u.data FROM node n INNER JOIN users u ON u.uid = n.uid INNER JOIN node_revisions r ON r.vid = n.vid WHERE n.nid = 4571
26.98 1 cache_get SELECT data, created, headers, expire FROM cache_menu WHERE cid = '1:ru'
26.87 1 node_load SELECT n.nid, n.vid, n.type, n.status, n.created, n.changed, n.comment, n.promote, n.sticky, r.timestamp AS revision_timestamp, r.title, r.body, r.teaser, r.log, r.format, u.uid, u.name, u.picture, u.data FROM node n INNER JOIN users u ON u.uid = n.uid INNER JOIN node_revisions r ON r.vid = n.vid WHERE n.nid = 4371
25.46 1 drupal_lookup_path SELECT dst FROM url_alias WHERE src = 'node/4531'
21.12 1 node_load SELECT n.nid, n.vid, n.type, n.status, n.created, n.changed, n.comment, n.promote, n.sticky, r.timestamp AS revision_timestamp, r.title, r.body, r.teaser, r.log, r.format, u.uid, u.name, u.picture, u.data FROM node n INNER JOIN users u ON u.uid = n.uid INNER JOIN node_revisions r ON r.vid = n.vid WHERE n.nid = 4336
20.88 1 drupal_lookup_path SELECT dst FROM url_alias WHERE src = 'subscriptions/add/node/4508'
20.68 1 drupal_lookup_path SELECT dst FROM url_alias WHERE src = 'node/4342'
Это только то, что дольше 20.
Что-то с базой, я думаю? Простые запросы выполняются в 20-50 раз дольше. К чему бы это...
Кстати, сколько всего запросов?
Индексы слетели может? Или таблицы надо "оптимизировать"?
Похоже на отсутствие или неработоспособность индексов. В логах вебсервера какие-нибудь ошибки?
--
Администратор сайта «Drupal — Россия»
на вопросы по Drupal отвечаю только на форумах, не пишите в почту и приватом!
Понятно, что с базой что-то. Не могу понять что. Из ошибок в логах - эпизодическое: PHP Warning: MySQL server has gone away.
Индексы есть и не пустые.
Вопрос все тот же: делать-то чего?
Да.... очень весело. Попробовал SELECT DATA , created, headers, expire
FROM cache
WHERE cid = 'locale:ru'
в таблице 1(!) запись. Знаете сколько запрос занял?
Запрос занял 1.0147 сек
Очень блин весело.
а ты просто сам руками создай новую базу и в ней новую таблицу с двумя полями и одним индексом
потом попробуй вытащить чтото из этой таблицы SELECT * FROM новаятаблица WHERE первоеполе = 'чемуто'
и посмотри как всё это выполнится. Если будет долго, значит проблемма с самим mysql, если нет.
Значит нужно лечить таблицы в твоей базе, возможно пересоздавать индексы.
Ага, сделал.
Запрос занял 0.0026 сек
Итого - проблема в таблицах. Как лечить их?
потыкай в phpmyadmin, там есть всякие repair и т.д. - вдруг поможет
да тыкал уже. безрезультатно.
Возьми любой свой медленный запрос и сделай EXPLAIN для него. Увидишь, что и как используется. Потом и будешь думать, в какую сторону копать
ты ещё посмотри какой тип таблицы на которой долго работает select
innodb или myisam
и какой тип у той тестовой таблицы которую ты создавал и на которой у тебя быстро запрос отработал.
может дело всё таки в mysql, а не в самих таблицах.
господа, я конечно в небольшом шоке пребываю, но не могу не поделится.
после длительного общения с сапортом выяснилось, что пятерке банально не хватает ресурсов.
поставил обратно 4.7, восстановил базу по бэку - все если не летает, то по крайней мере не тупит.
я вообще наивно полагал, что последняя версия оптимизирована лучше, а на практике (на шареде) 4.7 ее делает влегкую. разочарован.
"после длительного общения с сапортом выяснилось, что пятерке банально не хватает ресурсов."
ИМХО бред. Извините.
Проблема в чем-то другом. Не надо считать себя более умным и наблюдательным чем десятки или даже сотни разработчиков, которые тщательно исследуют и тестируют КАЖДОЕ изменения в ядре.
PS Вставил цитату для ясности. Рекомендую включить древовидный вывод комментариев.
Для пользы дела стоит сообщить:
какой хостинг,
какие ресурсы предоставляются,
каких именно не хватает "пятерке".
Тогда других предостережем "наступать на грабли" (например, пытаться ставить Drupal на вашем хостинге), да заодно, проверим, может быть, это саппорт просто хочет отвязаться от вас
не ясно, ты же сам писал:
== в таблице 1(!) запись. Знаете сколько запрос занял?
== Запрос занял 1.0147 сек
и сделал вывод:
== Итого - проблема в таблицах
При чём здесь версия Drupal?
Хм. Попробую обьяснить. Это не какая-то-там абстрактная таблица. Она в базе, которую "атакуют" запросами юзеры. Которые в свою очередь обращаются к ней посредством Друпала.
Я не берусь судить, что не так с запросами, но на отдельно взятом сервере на одной и той же базе 4.7 работает в 3 раза быстрее, чем 5.1
Как-то по-другому, кроме версии это можно обьяснить?
Ок.
Хостинг - Зенон.
Мускуль сервер - вроде как выделенный, в терминологии Зенона - персональный.
Не хватает - похоже памяти. Что приводит к принудительному завершению процессов.
Примерно вот так: exit signal Segmentation fault (11), possible coredump in
Друпал ставить можно и нужно. Отчего так именно с пятой версий - вопрос скорее к разработчикам.
А это с обновлённой версией?
А с новой инсталяцией Drupal'а пробовал?
Да, небольшое дополение. Мы говорим не о "пустом" сайте с почти нулевой посещаемостью. В базе около 5000 нодов, и около 100-150 юзеров (половина - регнутые) постоянно на сайте.
Так, чтобы понятно было, что база реально под нагрузкой находится.
Да, это была обновленная версия. Структуру таблиц апдейтил по настоятельному требованию Друпала.
Про новую инсталляцию - пробовал. Тупит, но поменьше. Ну оно и понятно, потому как скажем явно быстрее ничего не выводить, чем ковыряться в 50 с чем то там меговой базе поиска например.
Вот если честно не знаю в чем затык. Явно не в базе.
Может быть проект банально перерос рамки шареда? Возможно. Может шаред хорош, но "соседи" - дурят? Тоже возможно.
Очень обоснованное мнение, ничего не скажешь. Я не считаю себя или Вас умнее чем кто-то другой. Я довольно подробно (с цифрами) обрисовал проблему и попросил помощи. Только и всего.
> Про новую инсталляцию - пробовал. Тупит, но поменьше.
То есть тоже тормозит?
А если вручную (через phpMyAdmmin, например) делать запросы к БД (в новой инсталяции), быстро запросы выполняются?