Chikago: Хакают по выходным, так как люди нормальные отдыхают, а Агава хранит бэкап сутки, т.е. приходишь в понедельник, узнаешь что сайт в попе полной с пятницы и радуешься. 😡
так, а что мешает делать бэкап самим, хотябы дамп базы скидывать можно хоть каждый день на тот же @gmail.com :)
Chikago: Как выследить кто это сделал? В первый раз пробили айпишник, нашли по адресу пожелую женщину, которая была не в курсах, все зависло. Видимо, ошибка была.
лучше постарались бы сделать так, чтобы это не повторилось:
1) поставьте на комп антивирус нормальный (рекомендую KIS)
2) проверьте все на вирусы, выкачайте сайт к себе на комп и проверьте все, возможно где-то в папках лежит шел-скрипт
3) смените ФТП пароли, а также пароли на почтовый ящик и на сам хостинг-аккаунт
broken: просто я морально не могу платить больше 1500р в месяц за впс. я за 1700 в hetznere целую железяку беру. жабо душить начинает с нашими ценниками. + кто же знал что с вполне адекватной ценой будут тормоза с диском. заранее никто не говорил.
а если есть дедик в hetzner'е, то зачем тебе ВПСка? :)
broken: акселератор кеширует прямо в память. так что только отдача статики+ запись и выборка из бд.
еще можно попробовать складывать сессии PHP в хранилище eAccelerator'а :)
также в настройках SMF выбрать агрессивное кеширование (уровень повыше поставить) eAccelerator/memcached, а также почаще в админке проводить "удалить незначительные логи" + "оптимизировать таблицы" :)
broken: я задавал вопрос техподдержке про диски, не сата ли стоят? ответ был уклончивый, что быстрые де мы не можем ставить ибо они не всем нужны.
ну у них и процессор десктопный, так что наличие десктопных дисков в принципе не удивительно, да и это не столь важно, главное, чтобы соотношение цена\качество удовлетворяло :)
хороший процессор, такой средне-бюджетный вариант, правда он не серверный, но это не главное, главное - как его загрузили вычислениями :)
broken: ну не скажите :) очень сильный прирост дает :)) главное памяти не жалеть.
до определенного момента дает, а потом как не крути, больше уже не выжать
кстати можно попробовать еще включить в nginx'е кеширование на такие локейшны как:
/index.php?action=profile
т.е. на все участки форума, которые не критичны к частым обновлениям
broken: штатный режим работы :) интересно, а диски ноды насколько от этого страдают? как представил себе как голова мечется по дорожкам....
ну если диски хорошие, серверные, а не бюджетные SATAшные, то в принципе они проработают отлично 2-3 года без проблем хоть в постоянно 100% нагруженном состоянии (конечно бывают исключения, но обычно браковки вылетают в течении первого месяца) :)
broken: seocore, тупо взять два впс помельче на разных нодах и сделать базу данных удаленной?
тогда будет конкретная деградация производительности, т.е. 20 сек. рендеринг странички - это будет еще оптимальным показателем...
а вот хостеру поставить отдельный сервер (с отдельным гигабитным шнурком до рабочей ноды) с SSD дисками под MySQL было бы очень кстати + выдавать на каждую ВПСку например по 5-20 баз в зависимости от тарифного плана, тогда бы и XEN'ки клиентов бегали бы шустрее и клиентам приятно и хостеру не так уж и расходно :)
или хотябы экономичный вариант - на ноду влепить отдельный шустрый диск(и) и сделать одну XENку чисто под БД, оптимизировать все хорошо чисто под БД)
просто когда БД клиентские лежат в одном дисковом пространстве (пусть даже RAID-10/50), то при активном свопинге время позиционирования по диску (для БД как раз очень важно) возрастает до очень больших значений и деградирует всю производительность ноды, клиент конечно может там у себя крутить key_buffer, sort_buffer_size/read_buffer_size/read_rnd_buffer_size, но это все не поможет при активных insert'ах, так как в любом случае нужно производить запись на диск, да и query-кеш тут уже мало чем поможет :)
PS: можно попробовать часть таблиц перекинуть в MEMORY хранилище, это значительно разгрузит систему, только надо понимать, что содержимое MEMORY таблиц стирается при банальной перезагрузке (хотя в SMF полно хлама - те же логи-модерации и т.п., которых не жалко потерять), также советую выключить диск-хранилище в eAccelerator'е, так как он порождает серьезную фрагментацию диска (как бы мне тут не доказывали то, что в линухе фрагментации нет), также можно создать блочные (файловые) устройства, и разделить в них БД, /var/log + /tmp, - это снизит фрагментацию и в теории повысит быстродействие :)
Brim.ru: XEN не виноват, надо разумно сервер настраивать. Как пример - данные с одного из наших серверов, который забит под завязку Xen VPS-клиентами, многие из которых свопируются, время пиковое
ну вот как может быть производительность, если идет множественная рандомная выборка (типичный свопинг)? - время доступа ухудшается при этом до безобразия, и скорость работы с БД падает...
вот если как-нить сконфигурировать так, чтобы юзеру предоставлялось под БД доп. дисковое пространство (в виде еще одного устройства) на 15к RPM дисках (или SSD) дисках - вот тогда решение было бы хорошее...
Andreyka: Да, каждому - по VPS. Типичный конфиг ноды для VPS, это 8xDrives, 9Gb RAM, 2xQuad Core. Запуск идет через NFS, каждый VPS получает 1 диск, 1G RAM, 1xЯдро.
ну это не катит для масс-ВПС-хостинга, а для VIP хостинга лучше уж OpenVZ - и гибче и как-то более адекватнее в плане отказоустойчивости, и вообще те же 8 дисков можно в RAID-50 (при наличии хорошего контроллера разумеется) и реализовать уж тогда лучше через VMWare или Hyper-V :)
broken: Полный список не привожу, напишу лишь про тех кто здесь бывает - Himiko, Bloody, df (differentlocal), Andreyka.
ну если эти не помогли, значит причина реально в хостере
broken: вердикт всех кто смотрел, был следующий - и так все настроено нормально, косяк хостера, его надо менять потому что....здесь были разные фразы, аргументов никто не предложил.
ну у хостера видимо дисковая система тормозит, все же хотят денежкофф, вот и сэкономили... XEN еще такая штука, парочка свопящихся ВПСок и деградация производительности всей ноды обеспечена :)
ArtemZ: Понапихали всего..последнее нужно было убрать, php понавесить как fastcgi через сокет к nginx, апач убрать
и как это решит проблему с диском?
линейная скорость чтения\записи дискового массива (например RAID-10 из 4-х дисков 1Тб) будет порядка 250Мб\сек, а рандомное чтение будет еле дотягивать 10Мб\сек, в результате при массивном свопинге скорость просядет так, что там как раз выше этих 10Мб не будет подниматься :)
то ли дело SSD диски, там что линейная, что рандомная - практически нет разницы, так как позиционирование практически мгновенно происходит - но редкие хостеры предоставляют VPS'ки на SSD'шниках :)
DLag: Вы сравнили серверную платформу брендовой сборки с десктопным миникомпьютером, собранным под соответствующие условия.
я сравнивал производительность платформы, что она из себя представляет это вторично...
во многих случаях сверх бюджетные дедики в бюджетных ДЦ - это по сути дела те же тауэр-декстопы, так что разница между "неттопами" и такими дедиками идет явно в пользу "неттопов"...
сравнивать десктопы и серверные платформы разумеется бесполезно, это разные вещи :)
DLag: Если вдруг HP решится поставить Атом на сервера своей сборки, тогда с ними и будете сравнивать.
кстати в декстопно-домашнем сегменте уже давно HP присмотрелась к Атому, вот пример:
т.е. можно ожидать в скором времени и нормальных законченных решений в 2U конструкции с кучей серверов (некий такой Blade-micro :) )
причем реализовать для них единый KVM, один общий SAN массив на все серверы горазда проще и дешевле, чем это реализовывать отдельными решениями в стандартной стойке
по сути дела можно получить мощный кластер размером в 2U, по производительности превышающий целую стойку "средних" по мощности\цене серверов :)
Хакают по выходным, так как люди нормальные отдыхают, а Агава хранит бэкап сутки, т.е. приходишь в понедельник, узнаешь что сайт в попе полной с пятницы и радуешься. 😡
так, а что мешает делать бэкап самим, хотябы дамп базы скидывать можно хоть каждый день на тот же @gmail.com :)
Как выследить кто это сделал? В первый раз пробили айпишник, нашли по адресу пожелую женщину, которая была не в курсах, все зависло. Видимо, ошибка была.
лучше постарались бы сделать так, чтобы это не повторилось:
1) поставьте на комп антивирус нормальный (рекомендую KIS)
2) проверьте все на вирусы, выкачайте сайт к себе на комп и проверьте все, возможно где-то в папках лежит шел-скрипт
3) смените ФТП пароли, а также пароли на почтовый ящик и на сам хостинг-аккаунт
4) обновляйте движок чаще
просто я морально не могу платить больше 1500р в месяц за впс. я за 1700 в hetznere целую железяку беру. жабо душить начинает с нашими ценниками. + кто же знал что с вполне адекватной ценой будут тормоза с диском. заранее никто не говорил.
а если есть дедик в hetzner'е, то зачем тебе ВПСка? :)
акселератор кеширует прямо в память. так что только отдача статики+ запись и выборка из бд.
еще можно попробовать складывать сессии PHP в хранилище eAccelerator'а :)
также в настройках SMF выбрать агрессивное кеширование (уровень повыше поставить) eAccelerator/memcached, а также почаще в админке проводить "удалить незначительные логи" + "оптимизировать таблицы" :)
я задавал вопрос техподдержке про диски, не сата ли стоят? ответ был уклончивый, что быстрые де мы не можем ставить ибо они не всем нужны.
ну у них и процессор десктопный, так что наличие десктопных дисков в принципе не удивительно, да и это не столь важно, главное, чтобы соотношение цена\качество удовлетворяло :)
нода - Intel(R) Core(TM)2 Quad CPU Q9300 @ 2.50GHz 2499.952 Mhz
хороший процессор, такой средне-бюджетный вариант, правда он не серверный, но это не главное, главное - как его загрузили вычислениями :)
ну не скажите :) очень сильный прирост дает :)) главное памяти не жалеть.
до определенного момента дает, а потом как не крути, больше уже не выжать
кстати можно попробовать еще включить в nginx'е кеширование на такие локейшны как:
/index.php?action=profile
т.е. на все участки форума, которые не критичны к частым обновлениям
штатный режим работы :) интересно, а диски ноды насколько от этого страдают? как представил себе как голова мечется по дорожкам....
ну если диски хорошие, серверные, а не бюджетные SATAшные, то в принципе они проработают отлично 2-3 года без проблем хоть в постоянно 100% нагруженном состоянии (конечно бывают исключения, но обычно браковки вылетают в течении первого месяца) :)
seocore, тупо взять два впс помельче на разных нодах и сделать базу данных удаленной?
тогда будет конкретная деградация производительности, т.е. 20 сек. рендеринг странички - это будет еще оптимальным показателем...
а вот хостеру поставить отдельный сервер (с отдельным гигабитным шнурком до рабочей ноды) с SSD дисками под MySQL было бы очень кстати + выдавать на каждую ВПСку например по 5-20 баз в зависимости от тарифного плана, тогда бы и XEN'ки клиентов бегали бы шустрее и клиентам приятно и хостеру не так уж и расходно :)
или хотябы экономичный вариант - на ноду влепить отдельный шустрый диск(и) и сделать одну XENку чисто под БД, оптимизировать все хорошо чисто под БД)
просто когда БД клиентские лежат в одном дисковом пространстве (пусть даже RAID-10/50), то при активном свопинге время позиционирования по диску (для БД как раз очень важно) возрастает до очень больших значений и деградирует всю производительность ноды, клиент конечно может там у себя крутить key_buffer, sort_buffer_size/read_buffer_size/read_rnd_buffer_size, но это все не поможет при активных insert'ах, так как в любом случае нужно производить запись на диск, да и query-кеш тут уже мало чем поможет :)
PS: можно попробовать часть таблиц перекинуть в MEMORY хранилище, это значительно разгрузит систему, только надо понимать, что содержимое MEMORY таблиц стирается при банальной перезагрузке (хотя в SMF полно хлама - те же логи-модерации и т.п., которых не жалко потерять), также советую выключить диск-хранилище в eAccelerator'е, так как он порождает серьезную фрагментацию диска (как бы мне тут не доказывали то, что в линухе фрагментации нет), также можно создать блочные (файловые) устройства, и разделить в них БД, /var/log + /tmp, - это снизит фрагментацию и в теории повысит быстродействие :)
XEN не виноват, надо разумно сервер настраивать. Как пример - данные с одного из наших серверов, который забит под завязку Xen VPS-клиентами, многие из которых свопируются, время пиковое
ну вот как может быть производительность, если идет множественная рандомная выборка (типичный свопинг)? - время доступа ухудшается при этом до безобразия, и скорость работы с БД падает...
вот если как-нить сконфигурировать так, чтобы юзеру предоставлялось под БД доп. дисковое пространство (в виде еще одного устройства) на 15к RPM дисках (или SSD) дисках - вот тогда решение было бы хорошее...
Да, каждому - по VPS.
Типичный конфиг ноды для VPS, это 8xDrives, 9Gb RAM, 2xQuad Core. Запуск идет через NFS, каждый VPS получает 1 диск, 1G RAM, 1xЯдро.
ну это не катит для масс-ВПС-хостинга, а для VIP хостинга лучше уж OpenVZ - и гибче и как-то более адекватнее в плане отказоустойчивости, и вообще те же 8 дисков можно в RAID-50 (при наличии хорошего контроллера разумеется) и реализовать уж тогда лучше через VMWare или Hyper-V :)
Полный список не привожу, напишу лишь про тех кто здесь бывает - Himiko, Bloody, df (differentlocal), Andreyka.
ну если эти не помогли, значит причина реально в хостере
вердикт всех кто смотрел, был следующий - и так все настроено нормально, косяк хостера, его надо менять потому что....здесь были разные фразы, аргументов никто не предложил.
ну у хостера видимо дисковая система тормозит, все же хотят денежкофф, вот и сэкономили... XEN еще такая штука, парочка свопящихся ВПСок и деградация производительности всей ноды обеспечена :)
Понапихали всего..последнее нужно было убрать, php понавесить как fastcgi через сокет к nginx, апач убрать
и как это решит проблему с диском?
линейная скорость чтения\записи дискового массива (например RAID-10 из 4-х дисков 1Тб) будет порядка 250Мб\сек, а рандомное чтение будет еле дотягивать 10Мб\сек, в результате при массивном свопинге скорость просядет так, что там как раз выше этих 10Мб не будет подниматься :)
то ли дело SSD диски, там что линейная, что рандомная - практически нет разницы, так как позиционирование практически мгновенно происходит - но редкие хостеры предоставляют VPS'ки на SSD'шниках :)
cyber2, почему же мечты?
Все вполне реально, реализуется sql-запросами к базе.
вот, все реально, более того - востребовано, например дорвейщиками и любителями SAPE :D
Небитая ссылка
поставил бы rus-to-lat плагин и не мучался бы с битыми ссылками :)
Вы сравнили серверную платформу брендовой сборки с десктопным миникомпьютером, собранным под соответствующие условия.
я сравнивал производительность платформы, что она из себя представляет это вторично...
во многих случаях сверх бюджетные дедики в бюджетных ДЦ - это по сути дела те же тауэр-декстопы, так что разница между "неттопами" и такими дедиками идет явно в пользу "неттопов"...
сравнивать десктопы и серверные платформы разумеется бесполезно, это разные вещи :)
Если вдруг HP решится поставить Атом на сервера своей сборки, тогда с ними и будете сравнивать.
кстати в декстопно-домашнем сегменте уже давно HP присмотрелась к Атому, вот пример:
http://hard.compulenta.ru/423340/
а еще интереснее вот это:
http://www.xard.ru/post/14810/
т.е. можно ожидать в скором времени и нормальных законченных решений в 2U конструкции с кучей серверов (некий такой Blade-micro :) )
причем реализовать для них единый KVM, один общий SAN массив на все серверы горазда проще и дешевле, чем это реализовывать отдельными решениями в стандартной стойке
по сути дела можно получить мощный кластер размером в 2U, по производительности превышающий целую стойку "средних" по мощности\цене серверов :)