6 апреля 2012 в 14:42
Мой опыт работы в Друпал (7.12) ещё небольшой, понемногу учусь. В процессе разработки сайта на сервере приходилось довольно много ставить и удалять модули, и к тому же сайт двуязычный. Сейчас сайт постоянно вываливается после непродолжительной работы (минут 15) с такими ошибками и становится недоступным:
Error
The website encountered an unexpected error. Please try again later.
Error messagePDOException: SQLSTATE[42000]: Syntax error or access violation: 1226 User 'godwing7' has exceeded the 'max_questions' resource (current value: 75000) in lock_may_be_available() (line 167 of mysite/tmru/includes/lock.inc).
Ранее было:
Error
The website encountered an unexpected error. Please try again later.
Error messagePDOException: SQLSTATE[42000]: Syntax error or access violation: 1226 User 'godwing7' has exceeded the 'max_questions' resource (current value: 75000) in lock_may_be_available() (line 167 of mysite/tmru/includes/lock.inc).
Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator, cgiadmin@yourhostingaccount.com and inform them of the time the error occurred, and anything you might have done that may have caused the error.
More information about this error may be available in the server error log.
=====================================
Сейчас в базе данных 171 таблица, всего около 20 статей и 5 страниц. Тех.поддержка на Fatcow довольно оперативно исправляет доступ к сайту, но ошибка повторяется и повторяется.
Ранее они сообщили следующее:
Ultimately if you are encountering
'max_questions' resource (current value: 75000)
The maximum number of database queries per user is 75,000/hr. You will have to take a look at your database to find out what are causing these resources.
На сайта нет зарегистрированного пользователя “godwing7”, там только один пользователь, я как админ. Подскажите, как сделать полный поиск по базе данных? Я искал по ключевому слову “godwing7”, но ничего не нашел.
Прежде всего, я хотел бы спросить - при удалении модулей остаются ли от них таблицы в базе данных?
Может ли кто-нибудь подсказать, в чем причина этих ошибок?
Комментарии
Мож их DDOSят?
Причина этих ошибок в том, что у хостера установлено ограничение на количество запросов к БД в единицу времени(75000/час в вашем случае). Такое лимитирование вообще говоря не отражает нагрузки на сервер БД как таковой, и просто является самым простым решением для хостера по лимитированию нагрузки на серверБД, но и самым не правильным.
Drupal в свою очередь, делает очень много, но весьма лёгких запросов, и легко такие лимиты исчерпывает.
godwing7 - это ваш пользователь БД, никакого отношения к пользователям сайта он не имеет.
В общем, вам нужно сменить хостера.
DDOS? Не думаю, что это так, скорее всего дело в моей базе данных. Кстати вспомнил, godwing7 это моя регистрация в Livejournal, а связь туда идёт через кнопку Sharethis. Но почему это выдает ошибку?
Никакого ddos и никакой связи с ЖЖ. Прочтите внимательно мой ответ выше.
Легко сказать. Оплачено уже на пару лет вперед, переносить сайт - не уверен, что сумею его перевести.
***
Но кто подскажет насчет таблиц в базе, действительно ли они остаются при удалении модулей?
При правильном удалении модуля таблицы потрутся.
зачем на пару лет вперед то платили?на айти патруле вам бесплатно перенесут.тарифы от 100руб.
del
Дело в количестве запросов, а не в базе данных как таковой. Альтернативой смене хостера, только запинать их, чтобы они лимиты подняли посмотрев на собственно запросы, или просто убрали. Но очень сомневаюсь, что ради одного клиента что-то будут менять. Ещё одна альтернатива - озаботиться настройкой кеширования, пожалуй у вас только этот выход и остаётся.
Зайдите в /sites/default/config.php и посмотрите, какое имя пользователя БД там написано. И у вас отпадут всякие мысли о какой-то таинственной связи с ЖЖ.
Вообще-то я знаю, что при смене хостера, скажем c Fatcow на HostGator или GoDaddy, то деньги они переносят тоже, договариваются сами.
Да, вы оказались правы. Я как-то не обращал внимания на имя пользователя базы данных.
Получил письмо от тех.придержки Fatcow, что еще раз подтверждает правильность ваших мыслей:
«We apologize for any inconvenience this may have caused you. It appears that your account has exceeded the maximum query limit per hour. Maximum query limit on our server is set to 75000/hour.When you exceed the maximum query limit, your website will be taken offline. However, it will be reset by the end of the hour and the website will be activated. Example: If the script exceeds 75000 queries at 10:05 then in that whole hour, your website will be down and it will be up at 11:00.
If you feel that the connections will be more than the limit frequently, you can purchase additional query limits. If you wish to purchase this tool, then you can contact us back with the confirmation. The price for MySQL Query Limits tool is: $240.00/year, $60.00/quarter and $20.00/month. »
* * *
Это я один пользователь, лимит исчерпываю, а если люди будут регистрироваться на моём сайте, что тогда?
Вам же написали - меняйте хостинг!
ПыСы. Если вы только недавно купили хостинг, посмотрите,м ожет у них есть возврат средств (должен быть).
Хостинг купил более года назад, был простой HTML сайт, и месяц как перешел на Друпал.
Мне интересно, а что именно вызывает такое фантастическое количество запросов к базе данных, более 75000 в час? Это нормально? Какие модули это вызывают?
Какие должны быть настройки? Увеличить время кэша?
Если на сайте нет посещений, и вы один туда заходите, то надо искать проблему - столько запросов всё же быть не может. Это всё же 20 запросов в сек, чтобы исчерпать лимит за час. Поставьте модуль devel, посмотрите на статистику по запросам на разных страницах.
По поводу кеширования:
Во-первых его надо всё же включить, по умолчанию оно выключено.
Во-вторых кеширование у drupal не очень-то всё просто. Кроме кеширование в ядре, которое кстати, кеширует в базу данных, есть и другие модели для кеширования, и кеширование в различных модулях.
Если у вас в основном не зарегистрированные пользователи, имеет смысл посмотреть в сторону boost. Это может глобально решить проблему.
Также есть кеширование у views, но оно спасает скорее не от количества запросов, а от частого запуска довольно сложных запросов, генерируемых views.
Если много авторизированных пользователей, есть authcache - иначе для них кеширования не будет.
В общем тут не галочку одну поставить - надо думать и разбераться.
Спасибо Борис. Кэш был всегда включен, настроен на 15мин, увеличил до 30. Devel поставил, но это не для моего опыта, еле сайт восстановил. В режиме работы devel попробовал написать статью, по завершении она не сохранилась, с ошибкой (Warning: Invalid argument supplied for foreach() in form_type_checkboxes_value() (line 2251 of /mysite/tmru/includes/form.inc). Верхнее админ меню пропало, разлогинится было невозможно. user/logout не помогало. При нажатии переключения языка сайта (и др. ссылок) выскакивало окно скачивания какого-то файла. Пришлось удалить модуль на сервере.
Потом вываливалось: Fatal error: Unsupported operand types in /mysite/tmru/modules/block/block.module on line 349
Успел посмотреть, что при входе на сайт происходит около 180-300 запросов. Посмотрел на Boost, он ещё сырой. У меня наверное много модулей, подключенные 106 и Core- 36. Пока ошибки переполнения запросов нет. Вроде-бы всё нормально.
Странно, что есть проблемы какие-то с Devel, он обычно вполне нормально работает. У вас ядро не пропатчено случаем?
Да, под 7 пока Boost не зарелизен. Под неё вообще многое полезное не зарелизено на самом-то деле.
Куда столько модулей-то? Точно всё нужно?
Спасибо, Борис, за вопрос по модулям, возможно, что это одна из главных причин сбоев. Пока нет понимания масштаба, сколько допустимо устанавливать. Каждый модуль, это набор логики, а если логика становится многоходовой, риск ошибок увеличивается. Получается, что нужна централизованная управляющая надсистема, либо свой хороший опыт работы. Когда удалил Devel, то после этого сайт стал невероятно медленным, - 2мин.45сек загружалась главная страница, любые переходы больше минуты, кэш был активный. Техподдержка в Штатах также воспроизвела этот эффект, потом восстановили работу.
Update ядра, как и всех модулей - последней версии.
Я извиняюсь за длинный пост, но ниже публикую все свои активированные модули. Возможно другим пригодится для сравнения.
CORE
Aggregator
Block
Blog
Comment
Contact
Content translation
Contextual links
Dashboard - не пользуюсь
Database logging
Field
Field SQL storage
Field UI
File
Filter
Help
Image
List
Locale
Menu
Node
Number
OpenID - включил недавно, не уверен насколько он полезен.
Options
Overlay
Path
PHP filter
RDF
Search
Shortcut
Statistics
Syslog
System
Taxonomy
Text
Tracker
Update manager
User
ADMINISTRATION
Administration menu
Administration menu Toolbar style
AUTHENTICATION
Fbconnect
CHAOS TOOL SUITE
Chaos tools
Custom content panes
Page manager
Views content panes
CHARTING
Chart API - для Yandex.Metrics, но его статистика у меня на сайте на выводится, сообщает об отсутствии счетчика. На сайте Yandex все нормально.
CONTEXT
Context
Context Keywords
Context layouts
Context UI
DATE/TIME - нужен для простановки даты статей в поле транскриптов. Возможно избыточное решение.
Date
Date All Day
Date API
Date Context
Date Popup
Date Repeat API
Date Repeat Field
Date Tools
Date Views
DISPLAY SUITE
Display suite
Extras
Forms
Search display
FACEBOOK SOCIAL
Facebook Friends Invite
Facebook Stream Publish
FIELDS
Content Taxonomy
Content Taxonomy Autocomplete
MEDIA
IMCE
IMCE Crop
IMCE Mkdir
META TAGS (QUICK) - хотя я старательно вписываю метатеги в статьи, токен показывает, записи в полях [node:meta_description], [node:meta_keywords]и [node:meta_abstract] отсутствуют. В первых редакциях статей мететеги были, но при редактировании пропали.(?)
Extra functionality
Meta tags (quick)
Upgrade from nodewords
MULTILINGUAL
Localization update
MULTILINGUAL - INTERNATIONALIZATION
Block languages
Contact translation
Field translation
Internationalization
Menu translation
Multilingual content
Multilingual select
Path translation
String translation
Synchronize translations
Taxonomy translation
Translation redirect
Translation sets
Variable translation
OAUTH
OAuth
OAuth Provider UI
OTHER
Colorbox
FBConnect Test
Global Redirect
Libraries
Menu Block
Pathauto
SEO Checklist - возможно не нужен, он лишь информационный
Site Verification
Taxonomy menu form
Token
Transliteration
Twitter
Twitter actions
Twitter Post
Twitter Signin
Variable
Variable realm
Variable store
Yandex.Metrics
PANELS -
Mini panels
Panel nodes
Panels
Panels Extra Layouts
Panels In-Place Editor
SEO
Page Title
SHARING
ShareThis
SPAM CONTROL
CAPTCHA
Captcha Riddler
TAXONOMY MENU
Taxonomy Menu
USER INTERFACE
IMCE Wysiwyg API bridge
Wysiwyg
VIEWS
Views
Views UI
XML SITEMAP - вроде бы всё нормально, но среди файлов на сервере не могу найти
XML sitemap
XML sitemap custom
XML sitemap engines
XML sitemap internationalization
XML sitemap menu
XML sitemap node
XML sitemap taxonomy
XML sitemap user
***
Итого 92 модуля + Core 37шт. Подозреваю, что в базе данных осталось много мусора после переустановок модулей, сейчас 184 таблицы.
Есть ли какой инструмент, позволяющий отследить, какой модуль Друпала связан с какими таблицами?
Schema
Модуль Schema поставил, он обнаружил, что все мои таблицы отсутствуют в базе данных. Вверху высвечивается желтое предупреждение:
Field df_field_data_field_date.field_date_value: no Schema type for mysql type datetime.
Field df_field_revision_field_date.field_date_value: no Schema type for mysql type datetime.
Почитал английскую ветку, там обсуждают влияние модуля DATA (правда старой версии у меня обновленный), но говорят, что дело вроде бы не в нем. Поставил даже DEV версию модуля Schema, но сообщение то же.
догадливый какой, а будет нужен тебе супер сервер. Кошелек приготовил?
Сайт сам делал, бездумной накидкой кучи модулей?
да у него наверное под 1000 запросов на страницу. 75 раз обновил страницу, лимит и исчерпан.
Префиксы у таблиц есть?
Если будет на то Божья воля, то и на суперсервер сайт переведу. Бездумно ли модули накидываю? Наверное это справедливое замечание, создаю сайт и учусь на ходу, приходится экспериментировать, где-то спотыкаюсь, поэтому переустанавливаю модули. Как я понял, основная причина запросов - это счетчики. Убрал Rambler, Mail, Liveinternet, остались только Yandex и Google поскольку они с модулями. После этого впечатление, как будто с человека сняли кандалы с гирями - он стал бегать.
Префиксы dr_
Согласно сообщению:
Field df_field_data_field_date.field_date_value: no Schema type for mysql type datetime.
Field df_field_revision_field_date.field_date_value: no Schema type for mysql type datetime.
посмотрел, эти таблицы в базе есть. В модуле Schema под закладкой COMPARE > результат MISSING (187)- т.е. перечислены все мои модули с 187 таблицами; и EXTRA (190)- все таблицы из базы.
У Schema в семёрке проблема с префиксами
Понятно, спасибо. Буду удалять Schema.
***
На будущее: можно строить базу без префиксов? Что лучше?
Префиксы прежде всего нужны для того, чтобы с одной БД можно было бы работать нескольким сайтам на Drupal (ну или просто сайтам с пересекающимися именами таблиц), и чуть-чуть для безопасности.
Вполне можно делать без префиксов, если нет мультисайтинга и ограничения по количеству баз, меньшему чем кол-во сайтов.
Ясно. У меня один сайт, одна база для него. Не знаю, стоит ли переименовывать таблицы. После удаления лишних счетчиков стало намного лучше. Выскакивают разные мелочи, но терпимо.
Переименовывать не стоит.
То же самое
PDOException: SQLSTATE[08004] [1040] Too many connections in lock_may_be_available()...
Хламовая производительность у D7 вообще.
Или он сам такой тугой, или реально просто не вживается с ограниченным количеством запросов серваков. На локалке не пробовал, рискнул сразу сайт делать на хосте. Первый раз на семерке делаю. Красивая, а от скорости не в восторге.
Хостинг слабый..или модули какие то навороченые есть..
Могу сказать сейчас про свой сайт, что все более-менее нормально, хотя модулей ещё добавилось. Скорость отклика терпимая. Много ещё проблем и задач надо решить, на которые пока закрываю глаза, нужна рука профессионала. Но Drupal-7 я очень доволен, что выбрал именно его. Перед этим я пробовал Joomla и WordPress, у них своя ниша, ступенькой ниже чем Drupal. Так что производительность у D7 не "хламовая".
Не хотелось бы создавать новой темы, вопрос такой:
Если посмотрите на мой сайт, то там в основном тексты и немного иллюстраций. База данных - 50Мб. Но, когда я на хостинге пытаюсь заархивировать директорию всего сайта, то архив получается под 1 гигабайт (!). Откуда такое???! Этот архив я делал часто, и он рос как на дрожжах, прибавляя в весе по 100Мб за пару недель.
Подскажите, почему такое происходит, и что с этим делать? Где искать это прибавление, в каких директориях? Кэш у меня включен, постоянно его опустошаю в админ. панели.
Для того, чтобы посмотреть что в архиве - специальных знаний не требуется
Спасибо за подсказку. Оказалось это был модуль резервного копирования, с опциями без удаления старых архивов.