SaNV

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

Добрый день уважаемые форумчане! Подскажите, кто знает, подойдет ли память с частотой 400 (PC-3200) ECC на сервер HP DL360 G4 (с понижением частоты до 333), на котором уже стоит память 333 (PC-2700) ECC? Стоят 2 x Xeon 3GHz с шиной 800MHz. Может кто сталкивался, пробовал, знает. Заранее спасибо за ответы.

Я бы на вашем месте брал какой-то маломощный haswell на замену, чтобы не грелся и не шумел, и в тихий десктопный ящик с тихим десктопным кулером (серверные обычно шумные, даже самые тихие), с парой самсунгов 840 pro или интелов 520. И даже не смотрел бы на айбиэмы, дэлы и хапэ. Можно более детально по поводу этого haswell? Не приходилось сталкиваться... По поводу десктопного ящика есть несколько проблем, корпус тянет в себя очень много пыли, с пола и в полуметре от него (новый сервер будет висеть на стене в полуметре от пола, но крепление выдержит только до 20 кг, именно поэтому ищу 1U), через год непрерывной работы кулеры начинают гудеть как самолеты и постоянно кто-то что-то задевает на нем, что приводит к выключениям то питания, то сети... Был даже случай, когда манагер засиделся на работе, когда уходил зашел к нам и добросовестно выключил системник, который кто-то забыл выключить и он шумел. Правда быстро включил обратно, когда позвонили, но случай был забавный)))

Ну как это. ДНС есть же, его ждут, он должен ответить очень быстро, nginx тоже должен принять соединение очень быстро, никто локально на сервере не должен им мешать, т.е. обоим нужен чуть ли не рилтайм приоритет (-20). А вот почту никто не ждет, обработку логов никто не ждет, крон задачи никто не ждет - им всем нужно работать так, чтобы не мешать тем, кого кто-то ждет, т.е. дать им +20. Согласен, но в том то и дело, что nginx отвечает сразу (а значит и DNS тоже), но получение контента (динамически генерируемого) в пиках занимает много времени (порой 20-30 сек). По моим подозрениям тормозит где-то на уровне PHP+MySQL. Хотя не уверен. Если честно не разбирался детально, задача подобрать под эти задачи другой сервер, чтобы старый уже списать наконец, 10+ лет трудится, пора уже ему на покой)

Интересная мысль. Но ведь МТА не грузит систему на столько сильно, чтобы задумывать о новом сервере. Систему грузят резко навалившиеся любопытные пользователи. причем грузят не нагрузкой на мощность ЦП, а большим кол-вом запросов. ОЗУ распределена так, что ее хватает, но свободной нет, своп свободен на 95-100%, не замечал, чтобы он используется. Если APC отключить, то скорость генерации страниц падает в несколько раз (420 мс с выключенным против 270 мс с включенным), под нагрузкой я не рискнул проверять как без него работают сайты. По поводу покупки доп оборудовани согласен, что не лучшее решение, но сервер уже совсем старый, более 10 лет ему и думаю хороший повод поменять. Если сейчас все оптимизировать и вдруг оно начнет лучше справляться с нагрузкой, я потом не обосную необходимость покупки более нового и мощного сервера. На новом само собой все будет настраиваться снова и оптимизироваться. За наводки для оптимизации спасибо, взял на карандаш, обязательно учту!

Так вы так никогда от проблем не избавитесь, всплески (пики) нужно нормализовывать, хотя бы limit_req'ом в нджинксе (если они вызваны запросами пользователей конечно), приоритеты на процессы расставлять, чтобы важные получали больше CPU и I/O дисков, а остальные работали только, когда никому не мешают и т.д. Плюс, если у вас фря, то у вас наверняка вообще нет I/O планировщика, т.е. какой-то процесс без проблем может сожрать все ресурсы дисков на столько времени, на сколько ему нужно, а остальные будут тупо блокироваться и ждать, от этого наверняка и тормоза, и диски наверняка красным в gstat. Хотя мощный Xeon с SSD конечно решит проблему, и пока одна машинка - наверное так можно делать. Но это не решение, будет больше всплеск - снова будете побольше машину брать? Всплески не связаны с нагрузкой на дисковую систему, она то справляется, они связаны нехваткой ядер (потоков) для обработки запросов. Можно уменьшить количество процессов для nginx, PHP-FPM и для MySQL, но тогда будет вываливаться ошибка "Too many connections", что не есть хорошо, т.к. покупатель получив интересное предложение и не получив страницу с ним скорее всего обратно не вернется, а это вообще не вариант. Да и вообще необходимость такая стала, когда ген. директор получил письмо с предложением как и остальные несколько тыс. пользователей и ждал больше минуты, пока у него загрузится страница с предложением. После чего собрал нас и сказал: "Делайте что хотите, но чтобы такого больше не было. В разумных пределах и с адекватным бюджетом. О результатах отчитаетесь.". Я как начальник отдела был назначен ответственным. По поводу Ваших замечаний. На сервере нет не приоритетных процессов, все важны и нужны. В SSD острой необходимости не вижу (хотя в любой из 2ух выбранных мной серверов их можно поставить) , а вот пара мощных многоядерных ксеонов проблему однозначно решит. Вопрос только в какой из систем их брать (например из 2ух выбранных), в этом то и весь вопрос. А по поводу больших всплесков я уже думал. Когда такая проблема появится, то во-первых это будет связано с большим числом посещений, а значит и с большим числом покупок (прибыли), тогда буду раскошеливать на еще одну железяку, а потом еще одну, но при этом с разделением. Если 2, то на 1м сервере будет БД, а на другом все остальное. Если 3 сервера, то 1 - БД, 2 - это PHP-FPM с кешерами, 3 - nginx с медиа-контентом. Думаю таким образом проблема будет решена на долго и когда будет 3 сервера, думаю, руководство раскошелится на колокейшен, тогда шум будет уже не нашей проблемой...

Да, я знаю, расскажу проще: 1 сайт - это приложение, которое строит графики и выводит отчеты (таблицы) с суммарными/средними/минимальными/максимальными показателями. Активных клиентов там не много. Кто-то заходит пару раз в день, кто-то нескольк раз в месяц. Данные практически не изменяются, только добавляются, от 1 до 20 записей в минуту в каждую БД. Разные показатели хранятся в разных таблицах. Для примера, показатели за год занимают в таблицах 100к-1М записей. Причем кешировать их не получается, данные те же, а вот критерии отбора разные... Это OLTP, верно? Все остальные это разные сервисы, 2 магазина, сайт с набором статей, информационный сайт, сайт с АПИ для ограниченного использования (iOS + Android приложение).Все они используют БД с таблицами с малым кол-вом записей, 2-3к таблицы товаров в магазине, 10-15к характеристики, 5-7к отзывы, где-то так. Остальные таблицы до 1к записей и их не рассматриваю детально. Суть в том, что никаких вычислений нет, только выборка по запросу, иногда изменение, добавление, но 90% это запросы на чтение. Только сайт с API постоянно работает чтение/запись(обновление) в режиме близком к 50/50. Это все OLAP. Или я в чем-то ошибаюсь? Если да, то поправьте Все сайты свои, везде где можно было код/запросы оптимизировали, кеширование включили и работает это все не плохо на 2х процессорном, одноядерном сервере с 4Г памяти и 2 дисками SCSI 73ГБ в RAID1 на аппаратном контроллере с кешем, причем общая загрука составляет обычно не более 30% ресурсов. Но когда решают устроить распродажу на магазине и рассылают предложения по базе из 10к+ клиентов, начинается бум, какое-то время, пока идет рассылка ресурсы кушает МТА, а потом заинтересованные лица начинают переходить по ссылкам и создавать большую нагрузку, причем тормозят все сайты, благо такое бывает 1-2 раза в месяц и длится 10-15 мин, после все нормализуется. Задача не урезать кол-во одновременных подключений, а обеспечить всем желающим комфортную работу на сайтах. Причем судя по загрузке не хватает именно потоков, а не мощности ЦП....

Работа с БД тоже разная бывает. OLAP или OLTP? Вот об этом я и писал в своем посте, один сайт использует несколько БД (сейчас 3, постепенно добавлются) с таблицами больше 1М записей и постоянно растет (OLAP), а остальные используют таблицы с небольшим кол-вом данных (15-20к записей), но интенсивно (OLTP).

По поводу микросервера согласен с ValRevan. Задача вписаться в бюджет и при этом выбрать наиболее оптимальное, быстрое и надежное решение. Либо если и вылазить за пределы бюджета раза в 2, то не ради дорогой игрушки, а в реальное решение задачи. А если я куплю этот микросервер за $500 (при бюджете в $350), потом через пару месяцев попрошу проц еще за $300-$400 на память + проц сверх новый, быстрый и крутой, а потом еще через время, $400 на диски SSD, а в итоге при пиках нагрузки не будет хватать ядер (потоков) и все будет тормозить и падать. А если вдруг проц грохнется или планка памяти вылетит или еще какой-нить катаклизм? Простои, покупка нового (т.к. по гарантии ждать можно и месяц) и т.д. Как думаете, что мне начальство скажет на такое решение??

У вас же задача вроде несколько сайтиков по 1000 посетителей в сутки, откуда 1000 одновременных клиентов?Для вашей первоначальной задачи по CPU и атом потянет. По дискам: производительность только в них и будет упираться и то иногда. А производительность самого рейда, что софтового, что "аппаратного" на порядок-два выше, она вообще никакой роли здесь не играет. Лучше взять обычный SATA SSD и не заниматься ерундой. Ну во-первых нагрузка разная и в пике может превышать 1к. Во-вторых 1 посетитель как правило просматривает более 1 странцы, поэтому 1к одновременных подключений это не редкость. Самый простой пример - рассылка акций на почту посетителей приводит к нагрузке в несколько тыс просмотров в сутки минут на 15 стабильно. И в-третьих данные в базе разные и на одном сайте строятся отчеты из нескольких таблиц с количеством записей 1М+ и постоянно растет. Так что Атом не вариант вообще... Да, согласен, что производительность дисковой системы тут не критична, но исключать вообще ее не стоит, есть медиа-контент, который тоже будет периодически отдаваться пользователям и если нескольким посетителям вдруг захочется одновременно посмотреть видео ролики, причем большие и разные, упрется в файловую систему, что не есть гуд. По поводу SSD я уже думал и скорее всего поставлю со временм 2 для системы для работы с редко изменяемыми данными (например медиа-контент и скрипты сайта), но для БД он не пойдет, т.к. высокая интенсивность чтения/записи. При оценке нагрузки нужно учитывать не только отдачу статики, но и работу с БД, обработку запросов кэшерами (которых скорее всего будет 5+ демонов), скрипты, которые выполняются по крону, запросы ДНС и т.д. Это кажется, что мелочи, а 1-2 ядер не хватает, На существующем 2ух процессорном сервере в пики наблюдаем следующую картину: load averages 3.5 3.72 3.68 при загрузке проца всего 30-50%, а сайты начинают тормозить и грузтиться в 2-3 раза дольше обычного...

http://www.cpubenchmark.net/cpu.php?cpu=Intel+Xeon+E5420+%40+2.50GHz http://www.cpubenchmark.net/cpu.php?cpu=Intel+Xeon+E3-1270+V2+%40+3.50GHz Ну во-первых там стоит физически 2 таких ксеона. А во-вторых сколько такое производительное удовольствие стоит? Сколько выйдет такой сервер, если поменять проц на E3 и памяти добавить до 16ГБ?

Где гарантия, что если на плате стоит маркировка HP, то он ее сам спроектировал и собрал? По его заказу это может делать тот же LSI. Тестирует компоненты в сборе это да, это очень важно и очень нужно, а мы за это ему платим больше, чем аналогичные не брендовые решения. Все честно. Оба рейда используют контроллер (либо бортовой, либо дополнительный) к которому подключены диски (SCSI, SATA, SAS) и если сгорит он, то софт рейд работать тоже не будет, причем существует вероятность, что совсем, тут как повезет. Позвольте поинтересоваться, по какой причине сгорели эти контроллеры? По воводу советов и аргументов приведу придуманный, но жизненный пример: - Мне нужен грузовой тягач. Хочу грузы возить для внутренних нужд. На новый денег нет (не выделяют столько), поэтому хочу взять б/у. Посоветуйте. -- Да нафик технику б/у, хз сколько и как ее эксплуатировали. Нужно брать новый. Причем обязательно Мерседес. Потому, что это бренд, хороший и проверенный бренд. - Так денег же нет на новый... -- Ну тогда Вам лучше взять себе легковушку Мерседес. Например B или С класса. Вот новую можно купить чуть-чуть дороже, а за доплату можно купить прицеп, усилить раму, поставить фаркоп и будете возить свои грузы. - Ну так у нас грузов много и тяжелые, иногда очень, она же не потянет... -- Ну ничего, справится, будете перевозить по нескольку ходок, зато надежная, к тому же новая! И расход меньше и едет быстрее и выглядит стильно и красиво, а главное бренд! - Ну так у нес бывает много грузов срочных, которые нужно перевозить немедленно и в тот же день, иначе смысла нет. Мне кажется тягач все-таки лучше... -- Ну и что? Откажитесь от больших срочных грузов, берите не срочные или не большие и перевозите. Зато надежная - новая же, и запчасти и обслуживаение во много раз дешевле! Берите и не сомневайтесь, аргументы неоспоримые! Вот как выглядят Ваши советы и аргументы. Я написал еще в самом начале, что мне нужна железка для Веб хоть и с не большой, но стабильной нагрузкой и работать он должен 24/7, не завимо что там у него случилось (проц сгорел или память похекалась). Может рекомендуемый Вами NAS сервер обеспечить быструю, стабильную и бесперебойную работу сайтов с высоким уровнем доступности? Т.е. чтобы страницы не грузились по 5 минут при 1000+ одновременных клиентов?

Мы можем долго обсуждать какое решение лучше, где и почему. И каждый по-своему прав. Но хотелось бы все-таки получить советы по теме выбора сервера. Неужели ни у кого нет таких серверов на вооружении???

изучите HP P400 или P410 А изучать то нечего, тут на фотографии отчетливо видно, чип LSI, правда не видно какой модели...

Разница как раз принципиальна. Рейд собраный бортовым ICH9R у меня уже умирал вместе с матерью, и замена матери горюшку не помогла.Про разницу в обслуживании массива через биос или утилитой в ОС я вообще не упоминаю, бортовой рейд никто собственно рейдом то и не считает. Времена нынче немного не те, все об этом почему-то забывают. И для современного сервера обслуживание этого самого рейда с точки зрения рсурсов и скоростей абсолютно бесплатно. Значит Вам не повезло, на моей практике не умирали, работали долго и довольно стабильно при наличии УПС. А как Вы обслуживаете свой софтовый рейд? Не утилитами ОС случайно? Бортовой рейд лучше, чем ОСовский как минимум тем, что он платформонезависим. Хоть Linux, хоть Windows, хоть что угодно и все вместе. Для современного сервера обслуживание всего имеет значение с точки зрения ресурсов. Именно поэтому выбираются более быстре, надежные и эффективные ОС типа Linux. На сколько быстро, по Вашему мнению, будет работать такой рейд при пиковой загрузке (например ЦП 100%)? Софтовый рейд - это дешевое, простое и быстрое решение, но никак не надежное. Как и обычный ПК вместо сервера. Всему все время и место.У меня домашняя машина как раз таки с бортовой видяхой(AMD APU), и ее более чем достаточно. Рабочие все тем более бортовые, зачем в офисе гефорс титан? Для такого применения - да, бортовые карты лучшие в мире. Вот именно об этом я и говорю. А если играешь, как он будет работать? Лучше, чем физическая видюха? Для домашних нужд софотвого рейда с головой хватит, как и бортовой видюхи, к стати AMD APU имеет физически графический процессор ATI, а не эмуляция функций процессором. А вот в продакшн серверах, где важна скрость, надежность и высокий уровень доступности, простым и дешевым решениям места нет. Они попросту не справятся с поставленной задачей...

По этому бекапы и UPS наше все! Бекапы и UPS это само собой очень важные моменты в любом случае. Вот только лучше иметь бекапы и не иметь причины ими пользоваться, чем выкатывать их при каждом сбое, что чревато простоями, порой долгими... То-то владельцы апаратных рейдов мечутся как грешники на сковородке когда контроллер отправляется в страну вечной охоты... Тыкните пальцем хоть в одного... Не спорю, аппаратные контроллеры умирают, как и все, но я например еще не видел ни одного сдохшего железного контроллера (мне повезло?), кроме случаев, когда их палили или когда им уже по 5-7 лет (для работы в режиме 24/7 это много-много часов наработки причем под постоянной нагрузкой)... Был случай на прошлой работе, сдохла железка на Dell сервере (подозреваю, что спалили), поменяли на аналогичную (эта была снята с производства и купить было нельзя) и ничего не изменилось, все на месте, массив, диски, разделы, массив даже не деградировал, в оптимале завелся (RAID 10), вот только винда (2003 Server) не пережила смены контроллера - BSOD.

И какой, например, из этих контроллеров является важным компонентом, основным? ChipKill да, отличная фича, видел в действии, молодцы. А еще что есть мега классного и революционного, но своего собственного? "Системы удаленного управления и мониторинга" скорее плюшки и не уверен, что они у них лучше, чем у других. Кстати, у кого лучше, у HP, IBM или Dell? Матери и БП да, но их делают много производителей не хуже, да и они ничего нового не придумывают, кроме как распаять на плате уже придуманные компоненты и "подружить" их. Например какой RAID контроллер у HP/IBM свой? Если он называется по-своему это еще не значит, что в базе не лежит какой-нить Adaptec/LSI...

Прекрасно понимаю RAID "созданый биосом на ICH" и средствами ОС не имеют принципиальной разницы, за исключением того, что первый управляется микропрограммой в контроллере, а второй средствами ОС (помоему даже модулем, а не ядром). Софтовым рейд называется потому, что у него нет своего процессора и памяти, а использует ЦП и ОЗУ компьютера для обеспечения работы. Мне интересно, по Вашему мнению, "бортовые" видеокарты тоже лучшие в мире? Можно же сэмулировать частоту какую хочешь и памяти из ОЗУ можно выделить сколько угодно в пределах установленной и название какое-нить крутое можно придумать. Зато видеокарта за кучу денег не нужна и не сгорит если что. Прям сплошная экономия и выгода. Но от этого частота и канальность памяти не станет больше, не появятся широкие шины между GPU и памятью и у ЦП не вырастут шейдерные блоки, да и CPU никогда не станет GPU. Работать это чудо в режиме эмуляции будет очень медленно и грошь ему цена. Грубый пример, но суть такова, что каждый компонент должен заниматься тем, для чего предназначен.

Не поверите, сам. Не поверю. Интеловские чипы сам делает? Или процессоры? Или может борадкомовские/интеловские сетевые контроллеры? Или видео карты? Жесткие тоже?? Даже адаптековские/LSI контроллеры? И конечно же модули памяти, куда же без них? Да, все сам, все сам... Мат платы мб и собрает сам - не готов утверждать, но он их не придумывает/не внедряет какие-то революционные технологии, и скорее всего их кто-то делает другой.

1. Я имел ввиду если рейд создается на бортовом контроллере мат. платы аля ICH* 2. Знаю, но гораздо реже и либо из-за отказа оборудования (что приводит к повреждению и софтового рейда), либо по не внмательности/не опытности админа. Железный рейд работает как минимум быстрее, особенно при больших нагрузках т.к. для его работы используется специально оптимизированная микросхема, а не ЦП в режиме эмуляции + прямой кеш, а не ОЗУ. Софтовый рейд поднятый на ОС зависит от ОС и например Linux'овый не будет работать на FreeBSD или Win и наоборот. За функционирование софтового рейда отвечает ОС, а значит глюки в системе (зачастую из-за железа), драйвере еще чем-нибудь, влекут за собой нарушение целостности массива, а порой и разрушение. Дисковые операции работают медленнее за счет того, что работают на более высоком уровне, через ОС, что создает доп. нагрузку и задержки, тогда как аппаратные работают на уровне железа и прозрачно для ОС. Софтовый рейд в любом случае использует контроллер для доступа к дискам (иначе никак), а простой бортовой контроллер явно работает медленнее, чем железный. И например в случае софтового зеркала данные передаются в 2 одинаковых потока для каждого из дисков, что является двойной назрузкой на шину, котнтроллер, тогда как железный получает данные без дублирования и сам уже передает данные по внутренним каналам непосредственно на диски. На мой взгляд на фоне этого всего софтовый рейд годится только для домашнего использования с не критичными данными... 3. Это все умеет любой железный рейд, а если не умеет, значит не нужно (я уверен, что любой производитель добавил какую-то фичу в свои контроллеры, чтобы получить преимущество перед другими). А софтовый рейд может давать много плюшек, то толку от них мало. Зато полезных плюшек (изменение массива на лету без потери данных, добавление дисков в существующий массив) у него нет. Я не говорил, что софтовый рейд это плохо, просто у него ограниченное применение и свои определенные риски. Я на эти риски пойти не готов и жертвовать производительностью ради сомнительного преимущества (если оно есть) я не готов...

Читать умею. От того, меняется память и проц он не становится полноценным отказоустойчивым сервером. А HP где берет железо для своего оборудования? Неужели сам делает? Один плюс есть, сборка HP гарантирует совместимость компонентов, но за это мы переплачиваем на стоимости (а есть ли смысл?). К тому же у него назначение - домашний (бюджетный) NAS. Что общего у сервера хранения данных с веб-сервером? И чем же 9.2 лучше 8.1?

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

1. Как раз таки зависит от того железа, на котором создан и нет гарантии, что будет работать на другом. 2. Не факт, что если что-то случится с материнкой и/или рейдом массив останется жив + известны случаи, когда при глюках проца, ОС - разваливался напрочь софтовый рейд. 3. Что там можно гибко конфигурировать интересно?) Ага, а если данные, которые готовятся на запись в рейд и находятся в памяти (кэш программного рейда) вруг повреждены и память без ECC этого не узнает, то имеем поврежденные данные и по закону подлости критичные...

Ну да, 1 двух ядерный десктопный проц аля Celeron (Pentium), SATA диски, десктопная память (без ЕСС и т.д.). Отличный сервер, а главное отказоустойчивый. В таком случае проще взять обычный системник, будет и дешевле и лучше, только это все не подходит для нашего веб-сервера. Еще варианты есть? Не всегда новое ПО - лучшее решение, особенно для серверных решений.

Пытался расставить. Получается половина требований есть у одного, а половина есть у другого. Так и не определился. Но за совет спасибо. Он будет висеть на стене в метре от пола, дисками (вентиляторами) вверх, понимаю, что пыль неизбежна, но не думаю, что в таких количествах, чтобы он забивался и перегревался. Сейчас стоит в корпусе Tower, но почти на полу, вот он точно пылесборник, чистить его приходится часто и не очень удобно, корпус приходится частично разбирать, вынимать вентиляторы, диски, иногда радиаторы. Стоечные сервер чистить на порядок проще, крышку верхнюю снял и вот оно все как на ладони) Я знаю, что ставятся они в отдельных помещениях, но к сожалению нет даже маленькой комнатушки, где его можно поставить, а уж тем более помещения с более-менее пригодными условиями для его нормальной работы (проветривание, кондер).