Покупка Сервера

adminius:

Прописные истины вроде...

но не для сервера БД.

очередное заблуждение. если сервер БД в качестве стоража использует продвинутую хранилку с большим кешем и офигительным количеством шпинделей - то он отлично будет вариться и на 256Мб... Кеш полезен тогда, когда массив загружен конкретно и чтобы облегчить ему жизнь, мы максимально кешируем данные. Чтобы хотя бы частично снять нагрузку с массива на чтение...

давай не будем впадать в крайности. то что можно сделать сервер вообще почти без оперативки и ворочающего при этом петабайтами информации в БД - не отрицаю. но - при этом не забываем сколько кэша будет стоять в этой самой "продвинутой хранилке". и её стоимость.

а мой ответ был отписан в плане того, что сервер серверу рознь. одному надо массив дисковый скоростной, второму - интерфейсы сетевые побольше и пошустрее а третьему - камень чтобы бесконечный цикл выполнял за 5 секунд. ибо - задачи разные. и железка под почтовый сервер не сильно подойдёт под нужды сервера БД. так же как и быстрый файлопомоечный ящик слабо будет справляццо с задачей брандмауэра для конторы в 200-300 мест.

Andrikos:

...

все правильно.

замена железа это тупиковый вариант.

простое добавление нужных индексов на базе как правило увеличивает производительность на порядок

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

после опитмизации он начал выполняться за 20 минут.

и на самом деле, бросает вас в крайности...

код выделить все

----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai hiq si| read writ| recv send| in out | int csw
35 1 63 0 0 0|1328k 3166k| 0 0 |1296B 1534B|7638 5134
35 1 64 0 0 0| 32k 636k|1263k 5409k| 0 0 | 10k 4792
47 1 52 0 0 0| 0 880k| 980k 5335k| 0 0 | 12k 5574
34 1 65 0 0 0| 528k 824k| 666k 4609k| 0 0 |8882 5129
33 0 66 0 0 0| 0 752k| 792k 3760k| 0 0 |9018 4962
34 0 65 0 0 0| 0 696k| 731k 3722k| 0 0 |8523 4536
39 1 60 0 0 0| 0 656k| 689k 3453k| 0 0 |8877 5571
60 1 38 0 0 0| 0 1104k|1089k 5635k| 0 0 | 12k 6006
54 1 45 0 0 0| 0 1232k|1128k 4479k| 0 0 | 13k 6712
52 1 45 1 0 0|8192B 2592k| 825k 5734k| 0 0 | 12k 5601
42 1 57 0 0 0| 56k 2256k|1050k 4845k| 0 0 | 11k 6029
40 1 60 0 0 0| 40k 1024k|1042k 5722k| 0 0 | 11k 5130
45 1 53 1 0 0|8192B 832k| 716k 3567k| 0 0 | 10k 5844
52 3 45 0 0 0| 0 1056k| 690k 4195k| 0 0 | 11k 5246
52 1 47 0 0 0| 464k 1432k| 808k 3894k| 0 0 | 11k 5244

qps now: 806 Slow qps: 0.0 Threads: 43 ( 6/ 12) 08/00/00/00 Key Efficiency: 88.6% Bps in/out: 0.0/ 4.0 Now in/out: 8.2/ 1.8k

1 [|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| 87.0%] Tasks: 140 total, 8 running
2 [||||||||||||||||||||||||||||||||||||||||||||||||||| 71.6%] Load average: 9.82 11.19 11.79
3 [||||||||||||||||||||||||||||||||||||||||||||||||||||| 75.5%] Uptime: 19 days, 22:21:00
4 [||||||||||||||||||||||||||||||||||||||||||||||||||||||||| 79.3%] Mem:32238M used:9460M buffers:828M cache:21550M
5 [|||||||||||||||||||||||||||||||||||||||||||||||||| 71.0%]
6 [|||||||||||||||||||||||||||||||||||||||||||||||| 67.5%]
7 [|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||95.4%]
8 [||||||||||||||||||||||||||||||||||||||||||||||||||||||||| 80.3%]
9 [|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||93.5%]
10 [||||||||||||||||||||||||||||||||||||||||||||||||| 68.0%]
11 [|||||||||||||||||||||||||||||||||||||||||||| 61.0%]
12 [||||||||||||||||||||||||||||||||||||||||||||||||| 69.1%]
13 [||||||||||||||||||||||||||||||||||||||| 54.5%]
14 [||||||||||||||||||||||||||||||||||||||||||||| 63.0%]
15 [|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| 83.7%]
16 [||||||||||||||||||||||||||||||||||||||||||||||||||||||||| 79.5%]
Mem[||||||||||||||||||||||||||||||||||||||||||||||||||||||||||9460/32238MB]
Swp[| 649/61035MB]

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

Я вижу вы не совсем понимаете что такое кеширование запросов.

Отчего же? Отлично понимаю. Как и механизм, как и механизм кеширования результатов выполнения функций к примеру.

У нормального конфига есть кеширование на уровне архитектуры БД, настроики БД, файловой системы ОС, на уровне RAID контролллера и на уровне диска.

А кто-то с этим спорит? Только вот в серьезных системах кеш на уровне диска если и работает, то исключительно на чтение. Но обычно его просто прибивают в прошивке.

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

Вы забыли добавить одно немаловажное условие - если данные статичны или близки к статичным и запросы типичные или близкие.

При 1000 QPS (запросов в секунду) никакие шпиндели не помогут. Как только загруженная БД начинает активно использовать диск для SELECT'ов - ей капец. Жесткий диск - чисто чтобы загрузится и сливать UPDATE'ы по мере накопления их в кеше записи.

Поверьте, есть такие ситуации, когда данные статичными не остаются в принципе, а меняются каждую секунду. Причем меняется не 1-2 записи. И на основании этих данные строятся отчеты. И именно в этом случае нужны те самые шпиндели и ИОПСы... Одно дело MySQL для форума к примеру и база в 10Гб, совсем другое дело Oracle в каком НацБанке и база в террабайт или больше...

А в целом говорим про одно и тоже... Только с разных позиций и в разных отраслях.

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

только за счет индексов? ой ли

svin0, теоретически проблем быть не должно, это обычный переходник по сути без контроллеров.

Вопрос, наверное, в эту тему. Подойдет ли стандартный (обычный, которых полно в инет-магазинах/на аукционах) pci riser переходник для стандартной atx платы?

Пример карты (на два pci):

одинарный да - а на фотке двойной , в любую такой не подойдёт

Господа!

Хочу затронуть тему не о серверах, но об одной компоненте нормальной телекоммуникационной стойки, а именно об IP-KVM. В РБ наличинствуют лишь китайские КВМ паршивого качества. Как показала моя практика их IP-модуль любит дохнуть насовсем в самый неподходящий момент. Сегодня сдохла очередная и это начинает напрягать. В данный момент в наличии уже 3 IP-KVM, которые стали лишь обычным KVM.

К сожалению есть серверы, где нет встроенного IPMI/iLO-модуля и их как-то надо подымать в критических ситуациях. КВМ китайские стоят тоже не дешево (16ти портовый около 1к евро), брендовые (HP, Aten, etc...) стоят ИМХО совершенно невменяемых денег (10к$).

Может есть какая альтернатива-то по ценнику?

продолжаем тему Blade или одиночные, раз уж надо все в куче

возвращаясь к теме Что взять: Blade или одиночные сервера?, хочу кое-что дополнить и добавить.

1 какие есть гарантии, что через пару лет будет современные лезвия под этот blade

hp c3000/с7000 будут развиваться до 2025 года, поэтому, даже через 5-10 лет вам не грозит иметь зоопарк различного оборудования и проблемы, связанные с этим.

плюс насколько я знаю у ХП есть программа - если контора покупает первую корзину в своей жизни, то шасси даются бесплатно.

кстати, действует до 31 марта : ) . но проводится регулярно. это, серьезная экономия.

к тому же, шасси берет на себя некоторые "обязанности", типа общего DVD, KVM, блоков питания, общего контроля системы и базовых настроек и как уже было сказано, блоки питания дублируются и быстро заменяются.

m_avrishe,

1 я имею ввиду совместимость

2 под модернизацией я не имею ввиду uprgade конкретного сервера, а замена целиком и возможность использование замененного для других целей

сейчас в различных подразделениях распределенных по всей РБ, но с большей концентрацией в Гомельской области, стоит дополнительный DC для нормальной работы этого подразделения, он же их файло-помойка и т.д. И им хватит одного сервера и смысла брать и им корзину - я не вижу

3 хоть balde и имеет кучу резервов, но они все внутри корзины, т.е. узкое место в том, что она ОДНА

4 про управление питанием: если не будет электричества, то мы сможем заглушить часть серверов сразу, после еще какие-нибудь и т.д. тем самым снижая нагрузку на ИБП. Какая понимаю у корзины минимальное потребление будет выше чем у нескольких отдельных серверов

5 заранее спланировать не всегда получается, хотя и надо