Новая тема   Ответить

 TGPtraffic_biz_inSect
Ну у меня с десяток доменов, где 100-200к галер суммарно в стриме. Теперь придется избавляться судя по всему.

 TGPtraffic_biz_inSect
Diablo II: Скажи, какие у тебя показатели по запросам к мускулю ?
У меня вот так
Max Average Current
queries 146 kq/m 102 kq/m 86 kq/m
slow queries 7 q/m 0 q/m 0 q/m

 Diablo
TGPtraffic_biz_inSect писал:

бро ,
я бы на твоем месте выкинул и стримы , и атх/атх3 ;
если надумаешь - стукай в аську , подскажу что делать ) будет по 250-300 мегабит легко с твоей тачки отдаваться

 Stek
Diablo II: а что вместо стримов советуешь для большого трафа ?

 adminZ
Видимо dtr )
Но лично мне в нем неудобная админка

 DiamonD
Так на мой вопрос и не ответил про базы, сколько, каков суммарный размер.. Ну да ладно..
Сравнивать с сиджами 3х летней давности нет никакого смысла.. Раньше как правило была одна морда с мелкими тумбами, сейчас мультикатегории, где число активных файлов для юникса в десятки раз больше..
Базы раньше были по 100-200 мег, сейчас у меня встречаются по 4 гига, соотв и железо надо лучше (тем более раньше и тип таблиц в мускуле попроще все использовали).
Оптимизировать надо мускуль, особенно если он юзает InnoDB таблицы (его вообще мало кто оптимизирует, а он требует до 80% памяти под себя при грамотном подходе). Статику надо выносить на отдельный сервер и ставить nginx само собой. Причем статика может быть меганавороченная, но всего-лишь один неверный параметр ядра убьет нафиг всю производительность (я про kern.maxvnodes говорю).
Простенькая связка 2х Dell R210/8/2*300 (динамика+статика) спокойно должна держать 10 доменов с базами 500-800мег и траффиком до 300-500к. И будет гораздо сложнее держать 50 доменов с такими же базами, но траффиком 50к..

 Dr.Syshalt
adminZ писал:

Я еще видел на живом, не жутко загруженном сервере, как он положил сервак, забив его файлами. Тоже как бы не идеален.

 adminZ
DiamonD писал:

Вначале нада смотреть не на размер базы, а на скрипты которые пишут горе-програмеры, где например под поле IP выделяют varchar(30), где индексы по которым запросы непроходят (или вобще нет индексов), где собсно запросы трехэтажные и нихера неоптимизированые. Есть куча примеров где разделение 1 запроса на 2 уменьшает время выполнения в 100 раз. Такой скрипт под нормальным трафом кластер сложит..

Ну и зачем тебе статика на отдельном серваке ? она использует совсем другие ресурсы, и спокойно работает на сервере вместе со скриптами (если конешно статики не Гбит )

 DiamonD
adminZ писал:

Ресурсы то другие, только память одна у сервера и диски тоже :-) А когда тумб активных под 500к суммарно, то лучше все это хозяйство поместить на отдельный сервер, да и удобно даже в случае переноса динамики на другой сервер (путь до тумб один и не надо их никуда копировать). А еще статика отдается с IP напрямую и можно легко настроить отдачу отдельно с Европы и Штатов.. В общем + гораздо больше, чем -.. Ну и конечно речь идет не о 5ти мегабитном траффике..

 TGPtraffic_biz_inSect
Народ, а кто имеет опыт настройки дедиков конкретно под СТримротаторы ( с базами мускуля под Гиг размером ) ? Буду благодарен.

 TGPtraffic_biz_inSect
Народ кто что посоветует ?
Кроны разнесли по времени - нагрузка на проц по МРТГ сразу в 2 раза упала, стабильно ниже 50%, но по команде top вижу следующее :
пиковая нагрузка на проц от апача доходит до 120%, от мускуля до 240% ! Насколько это нормально ?
Я б не волновался если бы не видел сам торможение админок скриптов и иногда bad gateway вылетает.
LA в районе 2.
Мускуль по МРТГ
Max Average Current
queries 78 kq/m 53 kq/m 50 kq/m
slow queries 2 q/m 0 q/m 0 q/m

 TGPtraffic_biz_inSect
DiamonD: А не мог бы ты уточнить про этот самый kern.maxvnodes ?

 Bere3ka
kern.maxvnodes
Файлы и каталоги в ядре представлены при помощи vnode (виртуальных узлов). Увеличение их числа может помочь уменьшить нагрузку на дисковую подсистему. Как правило, специальной настройки это значение не требует, однако, в некоторых случаях дисковая активность является узким местом, и система исчерпывает таблицу vnode, значение этой переменной следует увеличить. При этом необходимо оценить объем неактивной и свободной памяти.

Текущее количество использованных vnode можно посмотреть при помощи команды:

# sysctl vfs.numvnodes
vfs.numvnodes: 91349

Максимальное количество vnode, доступных системе:

# sysctl kern.maxvnodes
kern.maxvnodes: 100000

Если количество использованных vnode близко к максимуму, значение переменной kern.maxvnodes следует увеличить на 1000. Следите за динамикой изменения vfs.numvnodes. Если оно увеличивается, приближаясь к вновь установленному максимуму, процесс следует повторить. Изменение в распределении памяти должно быть видно в выводе утилиты top(1): больше памяти перейдет в разряд активной.

 zuborg
Bere3ka писал:
Не на 1000, а раза в полтора-два. Пока использование не станет на уровне 50-70% от лимита

 color
TGPtraffic_biz_inSect писал:
а сколько винтов?
по опыту - даже с рейдом вынос mysql на SSD очень помогает обычно, при нагруженном mysql. Даже если на MLC чипах SSD (но интеловский обязательно тогда)

 color
adminZ писал:
+1
И апач вообще нафиг снести, поставить php-fpm

 TGPtraffic_biz_inSect
SSD по словам реселлера у Лизвеба стоит разово 1000 евро, и потом помесячно какая-то сумма. И еще он мне сказал следующее :
Даже на СЛЦ ячейках количество перезаписей ограниченно, поэтому использовать ССД для Мускуля смысла нет.
Зато посоветовал вынести мускуль на отдельный сервер
Винтов 4 у меня - SAS винты, нагрузка распределяется между ними равномерно.
А галеры на мультинишевом сайте с 200 категориями - это если по 1000 в категории, то уже 200к на сайте.

 color
TGPtraffic_biz_inSect писал:
что-то совсем дорого, да еще и помесячная к 1000 евро... совсем ужас.
у нас от 30$ в месяц цены начинаются в месяц.
Видимо они просто не хотят их продавать )
По опыту - интеловские SSD - еще ни один не вылетел..
дешевые SuperTalent на MLC чипах - да, вылетают под нагрузкой довольно быстро, в течение года.