Долго выполняется простой запрос к mysql базе данных

[Макар]

Проблема скорее на стороне сервера, но вот как ее решить пока не придумал, поэтому решил обратиться к коллективному разуму 

Имеем: VDS проц 1 x 2,66 GHz RAM  1024 MB с установленной CentOS 5 и ISPlite панелью
из ручного вмешательства доустановлена gd2 библиотека
php-5.1.6-27.el5_5.3
mysql-server-5.0.77-4.el5_6.6

на выполнение php выделяется 128м и 30сек , оперативки достаточно, в среднем показывает 490мб занято из 1024
php работает как cgi
ssi разрешен

форум 2.0.1 почти не модифицированный и без всякой нагрузки. Зарегистрированных 2, посетителей 0
из модов
PortaMx 1.45
Watermark.light   
Aeva Media
Watermark.light for AEVA
dQuoteSelection
Default Avatar   
RedirectPage   
WYSIWYG Quick Reply

переодически постоянно возникает проблема - запросы к базе данных выполняются раз через десять с жуткими тормозами

время генерации страниц плавает от 0.04 до 22.435345 / 45.435345 сек

в логах апача ничего связанного или подозрительного применительно к mysql нет ...........

сачала грешил на портал (так как без него особых тормозов не замечалось) и его блок кто онлайн. При включенном дебаг режиме показывало что этот блок создает запрос выполняющийся по 19 сек.

Блок отключил, но не тут то было! Тормоза продолжаются 

Простейший запрос на обновление, для главной страницы

     UPDATE smf_log_activity
       SET
          hits = hits + 1
       WHERE date = '2011-12-14'
    файл .../Sources/Subs.php, строка 3038, что заняло 0.00041699 сек. и запросов: 22.02535605.

потом раз десять обновляю страницу, все нормально

      UPDATE smf_log_activity
       SET
          hits = hits + 1
       WHERE date = '2011-12-14'
    файл .../Sources/Subs.php, строка 3038, что заняло 0.00020504 сек. и запросов: 0.0496769.
с незначитильными вариациями...........

обновляю, обновляю, и опять получаю 22-30 сек    а запрос то один и тот же !!!

Для главной самого форума картина аналогичная

Код Выделить Развернуть

SELECT
          c.id_cat, c.name AS cat_name,
          b.id_board, b.name AS board_name, b.description,
          CASE WHEN b.redirect != '' THEN 1 ELSE 0 END AS is_redirect,
          b.num_posts, b.num_topics, b.unapproved_posts, b.unapproved_topics, b.id_parent,
          IFNULL(m.poster_time, 0) AS poster_time, IFNULL(mem.member_name, m.poster_name) AS poster_name,
          m.subject, m.id_topic, IFNULL(mem.real_name, m.poster_name) AS real_name,
         
          (IFNULL(lb.id_msg, 0) >= b.id_msg_updated) AS is_read, IFNULL(lb.id_msg, -1) + 1 AS new_from,
          c.can_collapse, IFNULL(cc.id_member, 0) AS is_collapsed,
          IFNULL(mem.id_member, 0) AS id_member, m.id_msg,
          IFNULL(mods_mem.id_member, 0) AS id_moderator, mods_mem.real_name AS mod_real_name
       FROM smf_boards AS b
          LEFT JOIN smf_categories AS c ON (c.id_cat = b.id_cat)
          LEFT JOIN smf_messages AS m ON (m.id_msg = b.id_last_msg)
          LEFT JOIN smf_members AS mem ON (mem.id_member = m.id_member)
          LEFT JOIN smf_log_boards AS lb ON (lb.id_board = b.id_board AND lb.id_member = 1)
          LEFT JOIN smf_collapsed_categories AS cc ON (cc.id_cat = c.id_cat AND cc.id_member = 1)
          LEFT JOIN smf_moderators AS mods ON (mods.id_board = b.id_board)
          LEFT JOIN smf_members AS mods_mem ON (mods_mem.id_member = mods.id_member)
       WHERE 1=1
          AND b.child_level BETWEEN 0 AND 1
    файл .../Sources/Subs-BoardIndex.php, строка 72, что заняло 0.00143003 сек. и запросов: 22.37993598.

      SELECT
          lo.id_member, lo.log_time, lo.id_spider, mem.real_name, mem.member_name, mem.show_online,
          mg.online_color, mg.id_group, mg.group_name
       FROM smf_log_online AS lo
          LEFT JOIN smf_members AS mem ON (mem.id_member = lo.id_member)
          LEFT JOIN smf_membergroups AS mg ON (mg.id_group = CASE WHEN mem.id_group = 0 THEN mem.id_post_group ELSE mem.id_group END)
    файл .../Sources/Subs-MembersOnline.php, строка 82, что заняло 0.00035691 сек. и запросов: 22.38380003.

      SELECT event_date, YEAR(event_date) AS year, title
       FROM smf_calendar_holidays
       WHERE event_date BETWEEN '2011-12-13' AND '2011-12-21'
          OR event_date BETWEEN '0004-12-13' AND '0004-12-21'
    файл .../Sources/Subs-Calendar.php, строка 285, что заняло 0.00031996 сек. и запросов: 22.38684607.

      SELECT id_member, real_name, YEAR(birthdate) AS birth_year, birthdate
       FROM smf_members
       WHERE YEAR(birthdate) != '0001'
          AND MONTH(birthdate) != 0
          AND DAYOFMONTH(birthdate) != 0
          AND YEAR(birthdate) <= 2011
          AND (
             DATE_FORMAT(birthdate, '2011-%m-%d') BETWEEN '2011-12-13' AND '2011-12-21'
          )
          AND is_activated = 1
    файл .../Sources/Subs-Calendar.php, строка 137, что заняло 0.00021195 сек. и запросов: 22.38731003.

      SELECT
          cal.id_event, cal.start_date, cal.end_date, cal.title, cal.id_member, cal.id_topic,
          cal.id_board, b.member_groups, t.id_first_msg, t.approved, b.id_board
       FROM smf_calendar AS cal
          LEFT JOIN smf_boards AS b ON (b.id_board = cal.id_board)
          LEFT JOIN smf_topics AS t ON (t.id_topic = cal.id_topic)
       WHERE cal.start_date <= '2011-12-21'
          AND cal.end_date >= '2011-12-13'
    файл .../Sources/Subs-Calendar.php, строка 188, что заняло 0.00038004 сек. и запросов: 22.38764596.

      UPDATE smf_log_activity
       SET
          hits = hits + 1
       WHERE date = '2011-12-14'
    файл .../Sources/Subs.php, строка 3038, что заняло 0.00020099 сек. и запросов: 22.38864803.

Раз из десяти тормоз в запросах неимоверный, потом все нормально........

[Mr. Anviss]

Может это будет грубо но я просто взял и закешировал результат обращения к таблице calendar в файл. И если файл не был изменен в течении например 100 сек. то unserialize из файла в массив и тормоз снимается. Это прокатит с теми таблицами данные в которых редко (реже чем время кеширования) изменяются.