Pull to refresh
105
0
juks @juks

Пользователь

Send message
Когда просочились запросы, то самых страшных среди не было :-)
На форуме?

Сейчас всё, вроде бы, удалось решить, но говорить «много-мало» в данном случае как-то неправильно. Разве специфика отдельно взятых данных, структуры базы и запросов к ней ничего не решают? Разве можно сравнивать запросы одним только количеством :-)?

На хабре для каждого пользователя свои запросы и запросы довольно непростые, некоторые у меня не умещаются в экран. Чего стоит один только вывод постов и комментариев одной лентой? Лично я бы допускать этого в таком виде не стал, но здесь это есть. Как следствие - «using temporary; using filesort». Все эти количества комментариев, персонализированные ленты многого стоят. Для любого зарегистрированного пользователя кеширование практически сходит на нет.
С 6.2 на 6.2. MySQL 5. Разница версии в одну десятую.

Процессоры — с AMD 64 на новые четёрыхядерные ксеоны.

Там кроме прочего, были явные проблемы с таблицами, которые могли всплыть от dump-restore. Когда всё было в myisam то средствами repair/analyze/myisamchk ничего сделать не получалось, они просто висли. Приходилось пересоздавать проблемную таблицу.
Пока к fastcgi меня жизнь не привела.

Когда я работал в mail.ru то на моём проекте использовался nginx+apache+mod_perl. К моменту ухода рекорд был 1800000 хитов на один сервер web+база (news.mail.ru).
Проблемы были две:

* оптимизатор MySQL под нагрузкой начинал сходить с ума и брать неоптимальный индексы, приходилось долго и упорно расставлять их везде в виде use index, запросов было много, поэтому это был очень раздражительный и муторный процесс.

У нас там не было такого количества пямяти, поэтому скинуть всё на innodb не удавалось.

* mod_perl «тёк» (да, не высвобождал память, но в каких-то слишком значительных количествах), поэтому апачи должны были перезапускаться время от времени по maxrequests
innodb_buffer_pool_size

The size in bytes of the memory buffer InnoDB uses to cache data and indexes of its tables. The larger you set this value, the less disk I/O is needed to access data in tables. On a dedicated database server, you may set this to up to 80% of the machine physical memory size. However, do not set it too large because competition for physical memory might cause paging in the operating system.

Насколько моя память помнит, для myisam основные опции — параметры для буфера запросов и сортировки, помню, что когда я этим занимался, я не нашёл ничего такого, что позволилось бы ему с ногами залезть в память. Может быть, конечно, я просто что-то упустил.

До момента предоставления значительного количества памяти mysql потреблял 100-300% ЦПУ (в системе числится 8 процессоров от двух четырёхядерных ксеонов), как только таблицы были переведены в innodb. С двумя гигабайтами потребление снизилось до 1-15% в обычном решиме и 100% в пиковом.
До 400000 запросов к бекэнду в сутки, так что от одной страницы от 3-5 до 50-70 запросов к базе.

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

За то видно, где предел myisam.
Nginx здесь непричём. Ему просто не ответил апач, а тот, в свою очередь, не дождался ответа от базы. Как решались проблемы с базой написано выше.
Без этого довольно громоздкий пхп-код собирался заново для каждого запроса. С ускорителем всё остаётся в shared-памяти используется повторно до тех пор, пока не изменится исходный код.
Разницу надо просто отмасштабировать на тот случай, когда нагрузка будет пиковой.
Nginx берёт на себя статику и делает это, как все знают, очень хорошо. Про наш довольно лёгкий апач, который ничего кроме php-скриптов не крутит, против fastcgi я бы не стал сейчас спорить, да и это пока не актуально.
MySQL это наше всё :-) После переезда на новые срервера Каравана пришлось попотеть, проблем, думаю, мало кто не заметил. Всё вдруг взбударажилось и встало ребром.

До конца не помогло подключение новых тредов для FreeBSD 6.2 и оптимизация структуры базы и запросов к ней.

Видимо, помимо прочего, просто совпали моменты переезда и то время, когда myisam (да-да, все таблицы с начала жизни проекта до недавного времени были в myisam) стал не к месту для такого проекта. Кратковременное запирание таблиц приводило к гигантской очереди, которая просто не могла рассосаться.

Спокойствие настало тогда, когда в добавок к остальному посты и комментарии были переведены в InnoDB и был выделен двухгигабайтный буфер памяти. InnoDB в отличии от myisam умеет очень хорошо распоряжаться оперативной памятью: хранить там не только закешированную информацию но и целые индексы таблиц.

innodb_additional_mem_pool_size = 16M
innodb_buffer_pool_size = 2G

Про то, как сдесь применить AdoDB пока ничего сказать не могу: не пользовался. Пока довольствуемся стандарным кешем запросов MySQL.
Я имел в виду, что это довольно злой сервер для текущей задачи. Он и без акселератора потянул бы нагрузку в разы больше этой. Просто захотелось чтобы он меньше ворочался, раз есть такая возможность.

С дисками я, пожалуй, неверный пример привёл. По iostat не удаётся уловить разницы, нужна большая нагрузка, в разы. Да и общий объём исходного кода маловат.
Да, shared memory. Сейчас выделено 25мегабайт на всех. Как раз:

Memory Size 26,214,336 Bytes
Memory Available 3,672,832 Bytes
Memory Allocated 22,541,504 Bytes
Cached Scripts 359

А как падал? Умирали апачи/запускались другие?
Это фронтенд с 8G памяти :-)
Не несёт-то не несёт, но в любом нормальном договоре нормального оператора строго сказано, что всякого рода нелегальной и нежелательной ботвой на предоставляемых ресурсах заниматься запрещено. Надо думать, это нужно для того, чтобы оставлять за собой право отстранить клиента от предосталвяемых услуг когда есть на то причины.

Information

Rating
Does not participate
Location
Удельная, Москва и Московская обл., Россия
Date of birth
Registered
Activity