[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: Перегрузка БД sql и процессора
Гость_Александр
Сайт на CMS Joomla (php+sql) работает на виртуальном хостинге (unix). Даже при обращении (открытии) к 10 страницам в день возникает сильная перегрузка трафика к БД и нагрузка на процессор сервера из-зи именно этой БД. Хостер грозится отключить сайт.

Скажите пожалуйста:

1. Отчего это может быть - перегрузка из-за редкого обращения к сайту? Основные причины.

2. Как можно проверить какая процедура, функция, модуль конкретно вызывает перегрузку?

3. Может ли вызвать перегрузку опубликованные фото на сайте, если на странице только ссылка на фото, которые находятся на другом сервере (сайте)?

Спасибо.



Спустя 54 минуты, 23 секунды (1.10.2012 - 23:00) Invis1ble написал(а):
Цитата
1. Отчего это может быть - перегрузка из-за редкого обращения к сайту? Основные причины.

отчего угодно
Цитата
2. Как можно проверить какая процедура, функция, модуль конкретно вызывает перегрузку?

профилировать
Цитата
3. Может ли вызвать перегрузку опубликованные фото на сайте, если на странице только ссылка на фото, которые находятся на другом сервере (сайте)?

нет

Спустя 47 минут, 36 секунд (1.10.2012 - 23:48) Гость_Александр написал(а):
Цитата (Invis1ble @ 1.10.2012 - 23:00)
Цитата
2. Как можно проверить какая процедура, функция, модуль конкретно вызывает перегрузку?

профилировать

Спасибо большое. А поподробнее про "профилировать" можно? Что это значит? Что я должен в БД phpmyadmin сделать?
Спасибо.

Спустя 49 минут, 49 секунд (2.10.2012 - 00:38) inpost написал(а):
Надо проверять куски кода. Куском может быть от начала до конца скрипт. Делаем так:
в начале пишем: $i_time = microtime(true);
тут КУСОК кода, который проверяем
и в конце пишем: echo (microtime(true) - $i_time);

Открыли все страницы, посмотрели, кто сколько жрёт времени в секундах. На своём сайте я прописал абсолютно для всех страниц, и в БД вношу этот счётчик, потом смотрю, если какая-то страница даёт результат БОЛЕЕ 1 секунды, значит её надо ОПТИМИЗИРОВАТЬ, то есть переписать. Да хотя бы КЕШИРОВАНИЕ данных добавить.

Второй вариант, это на сервере попросить доступ к slow-query.log там и узнаешь какой запрос очень много кушает времени, значит отсутствуют индексы в таблице или она переполнена данными > 10млн. записей для простых таблиц.

Спустя 1 час, 58 минут, 31 секунда (2.10.2012 - 02:36) Гость_Александр написал(а):
Цитата (inpost @ 2.10.2012 - 00:38)
Надо проверять куски кода. Куском может быть от начала до конца скрипт. Делаем так:
в начале пишем: $i_time = microtime(true);
тут КУСОК кода, который проверяем
и в конце пишем: echo (microtime(true) - $i_time);

Открыли все страницы, посмотрели, кто сколько жрёт времени в секундах. На своём сайте я прописал абсолютно для всех страниц, и в БД вношу этот счётчик, потом смотрю, если какая-то страница даёт результат БОЛЕЕ 1 секунды, значит её надо ОПТИМИЗИРОВАТЬ, то есть переписать. Да хотя бы КЕШИРОВАНИЕ данных добавить.

Второй вариант, это на сервере попросить доступ к slow-query.log там и узнаешь какой запрос очень много кушает времени, значит отсутствуют индексы в таблице или она переполнена данными > 10млн. записей для простых таблиц.

Большое человеческое спасибо.
А если индексов нет, их можно вручную добавить? Как примерно?
Спасибо.

Спустя 10 часов, 2 минуты, 19 секунд (2.10.2012 - 12:38) inpost написал(а):
Гость_Александр
Конечно. Читай: "mysql индексы"

Спустя 5 часов, 22 минуты, 24 секунды (2.10.2012 - 18:01) Гость_Александр написал(а):
Цитата (inpost @ 2.10.2012 - 12:38)
Гость_Александр
Конечно. Читай: "mysql индексы"

ДРУГИ! Дело продвигается. Помогите пожалуйста еще немного. Хостер написал какие запросы перегружают. Можете ПО--РУССКИ перевести это ? :))Т.е. что происходит и что можно сделать чтобы таких запросов стало меньше, в каком направленгии копать?
Большое спасибо.
Хотя судя по текущим запросам к Вашей БД могу сказать что больше всего нагрузку создают подобный запросы:
===================================================================================================== =============================================================

# User@Host: p56267_kdoc[p56267_kdoc] @ [91.218.229.10]
# Thread_id: 31676017 Schema: p56267_kdoc Last_errno: 0 Killed: 0
# Query_time: 0.383857 Lock_time: 0.000329 Rows_sent: 5 Rows_examined: 5789 Rows_affected: 0 Rows_read: 5
# Bytes_sent: 35152 Tmp_tables: 5 Tmp_disk_tables: 1 Tmp_table_sizes: 89749144
use p56267_kdoc;
SET timestamp=1349135464;
SELECT a.fulltext, a.id, a.title, a.alias, a.title_alias, a.introtext, a.state, a.catid, a.created, a.created_by, a.created_by_alias, a.modified, a.modified_by,a.publish_up, a.publish_down, a.attribs, a.metadata, a.metakey, a.metadesc, a.access, a.hits, a.featured, a.ordering, c.alias AS category_alias, LENGTH(a.fulltext) AS readmore,a.fulltext, a.id, a.title, a.alias, a.title_alias, a.introtext, a.state, a.catid, a.created, a.created_by, a.created_by_alias, a.modified, a.modified_by,a.publish_up, a.publish_down, a.attribs, a.metadata, a.metakey, a.metadesc, a.access, a.hits, a.featured, a.ordering, c.alias AS category_alias, LENGTH(a.fulltext) AS readmore,c.title AS category_title, c.path AS category_route, c.access AS category_access, c.alias AS category_alias,CASE WHEN a.created_by_alias > ' ' THEN a.created_by_alias ELSE ua.name END AS author,ua.email AS author_email,contact.id as contactid,parent.title as parent_title, parent.id as parent_id, parent.path as parent_rou!
te, parent.alias as parent_alias,ROUND(v.rating_sum / v.rating_count, 0) AS rating, v.rating_count as rating_count,c.published, CASE WHEN badcats.id is null THEN c.published ELSE 0 END AS parents_published
FROM doc_content AS a
LEFT JOIN doc_content_frontpage AS fp ON fp.content_id = a.id
LEFT JOIN doc_categories AS c ON c.id = a.catid
LEFT JOIN doc_users AS ua ON ua.id = a.created_by
LEFT JOIN doc_users AS uam ON uam.id = a.modified_by
LEFT JOIN (
SELECT contact.user_id, MAX(contact.id) AS id, contact.language
FROM doc_contact_details AS contact
WHERE contact.published = 1
GROUP BY contact.user_id, contact.language) AS contact ON contact.user_id = a.created_by
LEFT JOIN doc_categories as parent ON parent.id = c.parent_id
LEFT JOIN doc_content_rating AS v ON a.id = v.content_id
LEFT OUTER JOIN (SELECT cat.id as id FROM doc_categories AS cat JOIN doc_categories AS parent ON cat.lft BETWEEN parent.lft AND parent.rgt WHERE parent.extension = 'com_content' AND parent.published != 1 GROUP BY cat.id ) AS badcats ON badcats.id = c.id
WHERE CASE WHEN badcats.id is null THEN a.state ELSE 0 END = 1 AND (a.publish_up = '0000-00-00 00:00:00' OR a.publish_up <= '2012-10-01 23:51:03') AND (a.publish_down = '0000-00-00 00:00:00' OR a.publish_down >= '2012-10-01 23:51:03')
GROUP BY a.id, a.title, a.alias, a.title_alias, a.introtext, a.checked_out, a.checked_out_time, a.catid, a.created, a.created_by, a.created_by_alias, a.created, a.modified, a.modified_by, uam.name, a.publish_up, a.attribs, a.metadata, a.metakey, a.metadesc, a.access, a.hits, a.xreference, a.featured, a.fulltext, a.state, a.publish_down, badcats.id, c.title, c.path, c.access, c.alias, uam.id, ua.name, ua.email, contact.id, parent.title, parent.id, parent.path, parent.alias, v.rating_sum, v.rating_count, c.published, c.lft, a.ordering, parent.lft, fp.ordering, c.id, a.images, a.urls
ORDER BY a.hits DESC LIMIT 0, 5;
===================================================================================================== =============================================================


Таких запросов много.

Спустя 2 часа, 32 минуты, 45 секунд (2.10.2012 - 20:34) Skadmit написал(а):
Отключи все подключенные к жумле модули, либо откажись от ее использования вовсе.

Спустя 54 минуты, 54 секунды (2.10.2012 - 21:29) inpost написал(а):
Сложный запрос. Ты либо сам переписывай код джумлы, либо модули изменяй, что должен делать очень легко любой программист работающий в джумле. Почему я так говорю: в начале программист учит ОСНОВЫ, а потом средние знания, а потом лишь CMS разбирает. Так что ты должен мочь разобраться в движке и подправить кривые модули.
А если сам не можешь, то либо нанимать программиста, либо удалять джумлу, либо начинать учить ПХП, а не движки. Вариантов не много, собственно...
Быстрый ответ:

 Графические смайлики |  Показывать подпись
Здесь расположена полная версия этой страницы.
Invision Power Board © 2001-2024 Invision Power Services, Inc.