X   Сообщение сайта
(Сообщение закроется через 3 секунды)



 

Здравствуйте, гость (

| Вход | Регистрация )

Открыть тему
Тема закрыта
> Нагрузка на сервер, сообщения от Вашего хостера.
depporter
depporter
Topic Starter сообщение 11.11.2008, 9:38; Ответить: depporter
Сообщение #1


Данной темой ничего не навязываю, а лишь высказываю свое скромное мнение. Думаю это будет полезно особенно новичкам. Старые волки делают оптимизацию сайта так, что некоторые вещи не знают даже бородатые админы хостингов. Сильно топик прошу не пинать и высказывать только объективные мнения. Так что новичкам посвящается....

Скорее всего каждый из Вас присутствующих на данном форуме получал от хостера письма с просьбами принять меры по снижению нагрузки. Это больше относится к большим сайтам или порталам, иногда достается и обычным "стартерам" с сайтом не более 5-10 страниц.

Что же делать если, Вы получили от хостера предупреждение.

Я сам работаю в хостинге, и занимаюсь клиентами, которые создают нагрузку, уточнять компанию не буду, да и незачем.

Ну так ближе к теме. Если вам хостер шлет необоснованное ничем предупреждение о нагрузке, то Вы вправе запросить логи и любые данные подтверждающие Ваше причастие к создаваемой нагрузке. Никогда не соглашайтесь и не верьте хостеру, утверждающему, что именно Вы создаете нагрузку, нужно самому в этом убедиться. Обычно бывает 3 вида нагрузки. Рассмотрим их.

1. Нагрузка на mysql.

Если Вы получили письмо просто с текстом в котором говорится, что Вы создаете нагрузку, то не стоит сразу лесть в phpmyadmin и копаться в базах, с учетом того, что Вы ничего не вносили. Необходимо запросить все запросы, которые создают нагрузку на сервер. При получении данных от хостера можно просто проанализировать полученные данные, по возможности принять меры, урезать запросы или переписать их полностью. Но также часто бывает, что на сервере кто либо другой подгружает мускул, но в ТОП попадает именно Ваш аккаунт, я в этом убедился на своих ошибках. В таком случае достаточно отписать хостеру, что принимаете меры, через сутки спросить у них, не снизилась ли нагрузка. Вот тут если ответят, что нагрузка держится, то следует уже разобраться. И последнее что хотел сказать по этому поводу - если не смотреть за базой длительное время, не проводить оптимизаций и т.д. то нагрузка неизбежна. Избежать естественного роста нагрузки со стороны базы можно делав хотя бы раз в 2 недели следующее.

Необходимо в консоли, если конечно хостер предоставляет ssh доступ, выполнить следующее:

mysqlcheck --repair --analyze --optimize --all-databases --auto-repair -u login -ppassword

Данная комманда почистит дырки в таблицах (дефрагментация), обновит статистику и отсортирует индексы.

Значение каждого ключа смотрите в манах, тут описывать не буду.


Далее опишу как делать НЕ стоит, это не мой труд, нашел на просторах сети, но тут довольно объективно рассмотрены ситуации.

Выборка всех полей

SELECT * FROM table;

При создании запросов избегайте, по возможности, выборки всех полей. Перечислите только те поля, которые вам действительно нужны. Кроме этого, не забывайте про покрывающие индексы. Даже если вам на необходимы все поля в таблице, лучше их перечислить. Во-первых, воспринимать код становится легче; во-вторых, со временем количество столбцов в вашей таблице может увеличиваться, соответственно выборка также будет расти.
Запросы в цикле

1. Выборки
$news_ids = get_list('SELECT news_id FROM today_news ');
while($news_id = get_next($news_ids))
$news[] = get_row('SELECT title, body FROM news WHERE news_id = '. $news_id);

Правило очень простое — чем меньше запросов, тем лучше (хотя из этого, как и из любого правила, есть исключения). Не забывайте про конструкцию IN(). Приведенный код можно написать одним запросом:
SELECT title, body FROM today_news INNER JOIN news USING(news_id);

2. Вставки
$log = parse_log();
while($record = next($log))
query('INSERT INTO logs SET value = '. $log['value']);

Гораздо более эффективно склеить и выполнить один запрос:
INSERT INTO logs (value) VALUES (...), (...);

3. Обновления
Иногда бывает нужно обновить несколько строк в одной таблице. Если обновляемое значение одинаковое, то все просто:
UPDATE news SET title='test' WHERE id IN (1, 2, 3).

Если изменяемое значение для каждой записи разное, то это можно сделать таким запросом:
UPDATE news SET
title = CASE
WHEN news_id = 1 THEN 'aa'
WHEN news_id = 2 THEN 'bb' END
WHERE news_id IN (1, 2)

Наши тесты показывают, что такой запрос выполняется в 2-3 раза быстрее, чем несколько отдельных запросов.
Выполнение операций над проиндексированными полями

SELECT user_id FROM users WHERE blogs_count * 2 = $value;

В таком запросе индекс использоваться не будет, даже если столбец blogs_count проиндексирован. Для того чтобы индекс использовался, над проиндексированным полем в запросе не должно выполняться преобразований. Для подобных запросов выносите функции преобразования в другую часть:
SELECT user_id FROM users WHERE blogs_count = $value / 2;

Аналогичный пример:
SELECT user_id FROM users WHERE TO_DAYS(CURRENT_DATE) — TO_DAYS(registered) <= 10;

не будет использовать индекс по полю registered, тогда как
SELECT user_id FROM users WHERE registered >= DATE_SUB(CURRENT_DATE, INTERVAL 10 DAY);
будет.
Выборка строк только для подсчета их количества

$result = mysql_query(«SELECT * FROM table», $link);
$num_rows = mysql_num_rows($result);
Если вам нужно выбрать количество строк, удовлетворяющих определенному условию, используйте запрос SELECT COUNT(*) FROM table, а не выбирайте все строки лишь для того, чтобы подсчитать их количество.
Выборка лишних строк

$result = mysql_query(«SELECT * FROM table1», $link);
while($row = mysql_fetch_assoc( $result) && $i < 20) {

}
Если вам нужны только n строк выборки, используйте LIMIT, вместо того, чтобы отбрасывать лишние строки в приложении.
Использование ORDER BY RAND()

SELECT * FROM table ORDER BY RAND() LIMIT 1;

Если в таблице больше, чем 4-5 тысяч строк, то ORDER BY RAND() будет работать очень медленно. Гораздо более эффективно будет выполнить два запроса:

Если в таблице auto_increment'ный первичный ключ и нет пропусков:
$rnd = rand(1, query('SELECT MAX(id) FROM table'));
$row = query('SELECT * FROM table WHERE id = '.$rnd);

либо:
$cnt = query('SELECT COUNT(*) FROM table');
$row = query('SELECT * FROM table LIMIT '.$cnt.', 1');
что, однако, также может выполняться долго при очень большом количестве строк в таблице.
Использование большого количества JOIN'ов

SELECT
v.video_id
a.name,
g.genre
FROM
videos AS v
LEFT JOIN
link_actors_videos AS la ON la.video_id = v.video_id
LEFT JOIN
actors AS a ON a.actor_id = la.actor_id
LEFT JOIN
link_genre_video AS lg ON lg.video_id = v.video_id
LEFT JOIN
genres AS g ON g.genre_id = lg.genre_id

Нужно помнить, что при связи таблиц "один-ко многим" количество строк в выборке будет расти при каждом очередном JOIN'е. Для подобных случаев целесообразнее бывает разбить подобный запрос на несколько простых.
Использование LIMIT

SELECT… FROM table LIMIT $start, $per_page;

Многие думают, что подобный запрос вернет $per_page записей (обычно 10-20) и поэтому сработает быстро. Он и сработает быстро для нескольких первых страниц. Но если количество записей велико, и нужно выполнить запрос SELECT… FROM table LIMIT 1000000, 1000020, то для выполнения такого запроса MySQL сначала выберет 1000020 записей, отбросит первый миллион и вернет 20. Это может быть вовсе не быстро. Тривиальных путей решения проблемы нет. Многие просто ограничивают количество доступных страниц разумным числом. Также можно ускорить подобные запросы использованием покрывающих индексов или сторонних решений (например sphinx).
Использование ON DUPLICATE KEY UPDATE

$row = query('SELECT * FROM table WHERE id=1');

if($row)
query('UPDATE table SET column = column + 1 WHERE id=1')
else
query('INSERT INTO table SET column = 1, id=1');

Подобную конструкцию можно заменить одним запросом, при условии наличия первичного или уникального ключа по полю id:
INSERT INTO table SET column = 1, id=1 ON DUPLICATE KEY UPDATE column = column + 1

2. Нагрузка на процессор


Если Вы получаете письма с предупреждением о том, что излишне нагружаете лимиты, то впервую очередь следует выяснить какие есть лимиты для Вашего тарифного плана и какие именно Вы превышаете, попросить лог, например suexec в котором будет видно если сервак рубил Ваши скрипты по каким либо лимитам. Если Вы получили все данные, в которых имеются указания на определенные скрипты, которые до сего момента не грузили сервак, то посмотрите, логи доступа (apache) к Вашему сайту, сравните время вылетания скриптов по лимитам и что было в это время в логе доступа. Зачастую возникают подобные проблемы и за нашего доблестного яндекса. Особенно это заметно в последнее время, потому, что комманда яндекса изменила алгоритм сканирования. Последнее было выясненно из переписки с Платоном. Что именно было изменено не раскрывается, есть информация, что проблема решается. Сам я провел анализ, и узнал что конкретно было изменено в алгоритме. К простым пользователям это не относится и поэтому рассказывать не буду. Расскажу лишь как спастись теперь от яндекса. Для того, чтобы Ваш сайт не вешался при индексации достаточно прописать в robots.txt -

User-agent: Yandex
Crawl-delay: 5


Данная запись задает таймут в 5 секунд, чтобы робот яндекса следующий запрос задавал не ранее, чем через 5 сек.

Если после этого, хостер продолжает отаковать Вас письмами о нагрузке, то чаще всего бывает достаточно организовать на сайте кэширование, с бООльшим временем жизни самого кэша, естественно если это не навредит Вашему сайту.

а вот если описанное выше не помогло, то стоит задуматься об оптимизации скриптов, которые Вам укажет сам хостер. Давать советов по оптимизации скриптов не буду, так как в каждом случае могут быть свои заморочки, а элементарное не пишу, потому, что темы эти заюзаны до дыр.

Надеюсь данная тема поможет кому либо в общение с хостером и решении проблем с нагрузкой без приобретения более дорогого тарифного плана.

3 Нагрузка почтой.


Обычно при покупке хостинга, люди начинают заводить почту вида info@domen.ru указывают данный ящик на новоиспеченном сайте. Делать это не следует по нескольким причинам. 1. у хостера очень часто бывают проблемы с почтой, в которых в 90% случаев сам хостер не виноват. 2. Если Ваша почта для домена расположена не на выделенном сервере, а как всегда это бывает, прямо в Вашем аккаунте, то у Вас появляется шанс быть заспамленным, можно прочитать задосеными только не пакетами а почтой. Конкуренты, которые желают вывести из строя сайт пробивают ящики именно которые расположены на домене и просто делают рассылку, в этот момент в ящик может падать очень много писем, что повлекет за собой много проблем таких как - система не будет успевать перезаписывать файл maildirsize и в лучшем случае упадет Ваш аккаунт, в худшем весь сервер. Единсвенное что радует, подобная атака не долговременна, до реагирование админов. Сделать такую атаку можно с любого VPS/VDS отправив в спул пару мильенов писем. Вдаваться в подробности как это сделать чтобы не попасть в фильтры на релеях хостеров и не быть заблоченным не будем. Подведу итог, не стоит создавать почту у хостера лишь для того, чтобы было. Создавать нужно только в том случае, если Вам действительно это необходимо. Почему? Сейчас объясню. Спам - чума нашего и думаю следующего века. Спамеры все равно раздобудут Ваш ящик, и будут слать туда свой спам, вы естественно постой не пользуетесь, и она будет копиться в ящике, пока не кончится свободное место, потом Вас хостер попросит почистить ящик, и это совсем не удовольствие чистить к примеру 600-700 тысяч писем спама в веб интерфейсе, который позволяет одновременно показать не более 200 писем. Конечно можно воспользоваться ssh, но лучше заблаговременно не создавать проблем.

Замечание модератора:
Эта тема была закрыта автоматически ввиду отсутствия активности в ней на протяжении 100+ дней.
Если Вы считаете ее актуальной и хотите оставить сообщение, то воспользуйтесь кнопкой
или обратитесь к любому из модераторов.


Сообщение отредактировал depporter - 11.11.2008, 9:41
0
Вернуться в начало страницы
 
Ответить с цитированием данного сообщения
Открыть тему
Тема закрыта
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0


Свернуть

> Похожие темы

  Тема Ответов Автор Просмотров Последний ответ
Открытая тема (нет новых ответов) Сервер для поднятия proxy ipv4
3 Panameira 2704 13.11.2018, 4:24
автор: zkalinin
Открытая тема (нет новых ответов) RegVPS.ru - Надежный VPS/VDS сервер на SSD от 3.95 usd!
0 Regvpsru 1785 2.12.2017, 22:23
автор: -Regvpsru-
Открытая тема (нет новых ответов) Нужно написать Api сервер для мобильного приложения
0 Ksardas777 1669 7.9.2016, 11:34
автор: Ksardas777
Открытая тема (нет новых ответов) Куплю сервер б/у
Куплю физический сервер
2 Leksandr0 2001 29.8.2016, 18:57
автор: Leksandr0
Открытая тема (нет новых ответов) Тема имеет прикрепленные файлыКачественно настрою Ваш VPS/VDS сервер
0 Dimkox 1776 16.3.2016, 0:46
автор: Dimkox


 



RSS Текстовая версия Сейчас: 29.3.2024, 1:19
Дизайн