Re: Железо сервера БД
Dmitry Yemanov wrote: А что, кеш в 4 гига выставить для большой БД никак? А интересно, кто пробовал такое делать?
Re[2]: Железо сервера БД
Привет! > Странно, почему никто не указывает варианта "Ось+temp" на обычный винт(ы), > а под базу - SSD. Вполне себе бюджетный и скоростной вариант. Потому, что интенсивная работа с SSD означает базу Шрёдингера - рано или поздно умрёт, но когда именно - узнаешь в неопределённый момент времени. И будет очень неприятно, если узнаешь об этом за пару часов до начала отпуска. Хотя да, "риальные поцаны" могут себе позволить очень шустрое хранилище от Sun/Oracle на 2 Тб, сплошь на скоростной памяти. Я считал, кирпич из серебра аналогичного веса стоит дешевле. -- Best regards, Sergeymailto:gebele...@gmail.com
Re: Железо сервера БД
13.07.2011 2:28, Dmitri Kuzmenko пишет: > можно я риторический вопрос задам, в пространство? > > Поскольку ситуация с "выбором железа" у людей, работающих с ФБ, > просто ну никуда, не могу понять. Неужели эти люди > никогда не интересовались скоростью работы диска? > Не запускали HDTune? Не читали никаких обзоров про сравнение дисков, > рэйдов, не способны понять выгоду от разделения IO, и т.д.? > Особенно феерично сталкиваться с таким незнанием у админов. > > [тут был еще абзац, но я его удалил :-) ] > А вот тут можно спорить, ведь если бюджет неограничен - понятно, ставь самые быстрые диски и камень по мощнее. Но речь идет о ограниченном бюджете, и сколько бы люди не читали обзоров (Не запускали HDTune), возникает вопрос: сколько и каких ресурсов нужно FB, для определенного профиля работы. Т.е. вложить больше денег: в процессор, hdd, raid контроллер. И вот здесь, полный информационный вакуум, как распределяется нагрузка по железу для FB при сценариях WEB бд, OLTP систем и т.д, при разном количестве пользователей. Сами сталкивались с этим, и если для oracle, mssql есть и рекомендации разработчиков, и готовые сервера оптимизированные под бд, и тесты, то для Firebird не нашли ни чего. Также последнее время на sql.ru постоянно возникают темы по инсталляции FB для нескольких сотен коннектов, и каждый из ТС начинает заново проходить все грабли по выбору, настройке ОС, настройке FB. Я это к тому, что на вашем сайте великолепная подборка материалов для начала освоения FB. Но люди растут, базы растут, не помешали бы статьи/тесты/рекомендации по более серьезным вопросам.
Re[2]: Железо сервера БД
Привет! >> Рекомендации от экстремалов: >> >> 1) Система на SSD, своп нафиг. > Серега, "своп нафиг" уже давно не смешно. Не нужно его выключать, > от этого один геморрой, и лучше не будет. > Собственно, ОС на SSD это не экстрим, это просто выкидывание > денег на ветер. Для ноутбуков - да, побыстрее загрузка. Ну про "система на SSD" я просто не стал человека пугать - некоторые вообще на флэшку пишут систему виртуализации (XEN/VMWARE) и грузят всё с винтов обычных потом. Позволяет не задумываться о конфигурации железа, если согласиться на 5% потерь производительности и на одну виртуалку на одной железке. Но на SSD грузится быстрее :) > В остальном системе диск не особо нужен. Угу. По идее в винде тоже всё, что нужно система кэширует в оперативке - но на линуксах это проще контролировать (не холивару ради, самый короткий путь - тот, который ты знаешь). >> 2) TEMP - 4-8 гигов в оперативке, второй темп - в любом месте. > опять же, "экстрим" по поводу "TEMP в оперативке" обусловлен незнанием > факта, что IB/FB создают временные файлы как temporary, которые сама > ОС распределяет в памяти по мере необходимости. Правильно. Но наличие временной папки в оперативке гарантирует минимальный iowait при работе с временными файлами в *никсах. Справедливо ли то же самое в винде - хз, там вроде нет штатной возможности делать RAM-диски. > И выигрыша temp в RAM не дает никакого. Только глюки от таких > "виртуальных дисков". Это у вас, виндузятников, надо извращаться с RAM-дисками. У юниксятников оно "искаропки" и является штатным средством ;-). У меня есть система, которая пишет сырое видео в оперативку, конвертит его и складывает на винт. И весь софт уверен, что работает с обычными дисками. Только очень шустрыми. Вот на cтаром Xeon-е у немцев: root@auth:~# dd if=/dev/zero of=/dev/shm/zero bs=512M count=2 2+0 records in 2+0 records out 1073741824 bytes (1.1 GB) copied, 1.69637 s, 633 MB/s Или SOHO, но на Core i7 с трёхканальной памятью: root@adm-24hr:/home/developer# dd if=/dev/zero of=/dev/shm/zero bs=512M count=2 2+0 records in 2+0 records out 1073741824 bytes (1.1 GB) copied, 0.814282 s, 1.3 GB/s А вот у настоящих "кульных пацанофф" на белых и пушистых серверах с ECC: root@ms2:~# dd if=/dev/zero of=/dev/shm/zero bs=512M count=2 2+0 records in 2+0 records out 1073741824 bytes (1.1 GB) copied, 1.08713 s, 988 MB/s Ну какой винт даст такую скорость? ;-) -- Best regards, Sergeymailto:gebele...@gmail.com
Re[2]: Железо сервера БД
Привет! >> Если система ушла в своп - то где бы он не располагался - настаёт она >> самая - ж.о.п.а. Поэтому, пусть лучше памяти будет много. > Своп вроде бы всегда используется виндой для своих нужд. Это у вас на венде. У Пингвинов немного не так: serj@auth:~$ free total used free sharedbuffers cached Mem: 16475204 104827605992444 0 1808887813916 -/+ buffers/cache:2487956 13987248 Swap: 31246264 0 31246264 Т.е. он как бы есть и его даже можно использовать, но в обычных обстоятельствах - память нынче дешёвая. >> Тогда кэша страниц побольше, 64-битные сборки хорошо память жрать >> умеют :0) > Кстати, есть какая польза от 64-битного супера? > Вроде максимальный размер кэша как то лимитирован. Влад говорил, что выставить можно 100к страниц и оно не подавится. Но это пусть лучше он прокомментирует. Я супер буду от тройки мучать, а с 1-2 как-то не особо сложилось, хотя для веб-приложений - самое то, там много мелких запросиков. Но мне хватает классика. -- Best regards, Sergeymailto:gebele...@gmail.com
Re: Железо сервера БД
12.07.2011 20:22, Dmitri Kuzmenko пишет: Кстати, есть какая польза от 64-битного супера? Вроде максимальный размер кэша как то лимитирован. пользы нет, только если ты не упрешься вдруг в нехватку памяти на 32-битном супере (2гига). Таких значений, если я правильно помню, достигают люди только с утечками памяти в udf. А что, кеш в 4 гига выставить для большой БД никак? Или типа с большими БД на супере не работают? :-) -- Дмитрий Еманов
Re: Железо сервера БД
Dmitri Kuzmenko wrote: Можно ли FW отключать или лучше оставить? отключать можно, если это ФБ 2.1 и выше (см. firebird.conf) Костыль однако. Но тем не менее... или если стоит raid с батарейкой. Но на raid с батарейкой может оказаться все равно, Fw=on или off. зависит от крутизны raid. Тут вопрос больше не в питании, а логических сбоях ОС, которые приведут к неконсистентности записи.
Re: Железо сервера БД
Dmitri Kuzmenko wrote: Время идет, рекомендации меняются. :-) - система - на отдельном винте - temp, база - можно на одном RAID 5 или 10 - бэкапы - на отдельном винте В целях экономии можно бэкап наверное делать на системный винт, а оттуда уже сливать по сети в надёжное место.
Re: Железо сервера БД
Dmitri Kuzmenko wrote: можно я риторический вопрос задам, в пространство? Поскольку ситуация с "выбором железа" у людей, работающих с ФБ, просто ну никуда, не могу понять. Неужели эти люди никогда не интересовались скоростью работы диска? Не запускали HDTune? Не читали никаких обзоров про сравнение дисков, рэйдов, не способны понять выгоду от разделения IO, и т.д.? Особенно феерично сталкиваться с таким незнанием у админов. С админов толку мало, т.к. они "широкого профиля". Тюнить FB всё равно разработчику. У нас просто пока не было столь высоких нагрузок, но сейчас стоит вопрос об установке нового сервера.
Re: Железо сервера БД
Hello, Alexey! Alexey Popov wrote: Никогда ещё не занимался комплектованием сервера для FB. Подскажите кое какие моменты. можно я риторический вопрос задам, в пространство? Поскольку ситуация с "выбором железа" у людей, работающих с ФБ, просто ну никуда, не могу понять. Неужели эти люди никогда не интересовались скоростью работы диска? Не запускали HDTune? Не читали никаких обзоров про сравнение дисков, рэйдов, не способны понять выгоду от разделения IO, и т.д.? Особенно феерично сталкиваться с таким незнанием у админов. [тут был еще абзац, но я его удалил :-) ] -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: Железо сервера БД
Hello, Alexey! Alexey Popov wrote: Своп вроде бы всегда используется виндой для своих нужд. не слушай его про "без свопа". Кстати, есть какая польза от 64-битного супера? Вроде максимальный размер кэша как то лимитирован. пользы нет, только если ты не упрешься вдруг в нехватку памяти на 32-битном супере (2гига). Таких значений, если я правильно помню, достигают люди только с утечками памяти в udf. В любом случае, на 64битной ОС заменить 32битный ФБ на 64битный - дело 30-ти секунд. Вот поменять разрядность ОС - это уже проблематично. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: Железо сервера БД
Hello, Sergey! Sergey Mereutsa wrote: Рекомендации от экстремалов: 1) Система на SSD, своп нафиг. Серега, "своп нафиг" уже давно не смешно. Не нужно его выключать, от этого один геморрой, и лучше не будет. Собственно, ОС на SSD это не экстрим, это просто выкидывание денег на ветер. Для ноутбуков - да, побыстрее загрузка. В остальном системе диск не особо нужен. 2) TEMP - 4-8 гигов в оперативке, второй темп - в любом месте. опять же, "экстрим" по поводу "TEMP в оперативке" обусловлен незнанием факта, что IB/FB создают временные файлы как temporary, которые сама ОС распределяет в памяти по мере необходимости. И выигрыша temp в RAM не дает никакого. Только глюки от таких "виртуальных дисков". -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: Железо сервера БД
Hello, Alexey! Alexey Popov wrote: Никогда ещё не занимался комплектованием сервера для FB. Подскажите кое какие моменты. Планируется поставить простой зеркальный райд под базу. ставь. Вопрос, надо ли ставить отдельный диск для системы, или тупо можно всё свалить на массив? да, и сделать один логический диск. И валить туда систему, темп, виртуал, базу, бэкапы, и прочий ХЛАМ. :-) Это сарказм. Если без сарказма, то уже давно даже для десктопов МС рекомендует машинки с ДВУМЯ дисками. Один система и софт, другой - работа и данные. Других на нагрузок кроме FB не будет. вопрос обслуживания, а не производительности. OS на raid это как правило геморрой. Поэтому лучше ОС на отдельный диск. Делать бэкапы такого диска просто, и в случае его гибели можно легко развернуть бэкап на ЛЮБОЙ диск за 50 баксов в ближайшем железном магазине. В случае ОС на raid и вылете raid придется бегать как ошпаренному, и искать ТАКОЙ ЖЕ диск в магазинах. (если кто-то возбудится на тему "дисков под сервер за 50 баксов", то я скажу, что по вопросу видно, что ответ про дисковые полки ценой от 10к баксов давать не надо. Но я и в этом случае посоветую ОС на отдельный диск, пусть не за 50 баксов, а за 300). Если памяти в принципе много, то сколько максимум можно отдать в кэш суперсерверу? Или всётаки файловый кэш ОС стправиться со своей задачей тоже эффективно. Можно ли FW отключать или лучше оставить? отключать можно, если это ФБ 2.1 и выше (см. firebird.conf) или если стоит raid с батарейкой. Но на raid с батарейкой может оказаться все равно, Fw=on или off. зависит от крутизны raid. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: Железо сервера БД
Sergey Mereutsa wrote: Если система ушла в своп - то где бы он не располагался - настаёт она самая - ж.о.п.а. Поэтому, пусть лучше памяти будет много. Своп вроде бы всегда используется виндой для своих нужд. Тогда кэша страниц побольше, 64-битные сборки хорошо память жрать умеют :0) Кстати, есть какая польза от 64-битного супера? Вроде максимальный размер кэша как то лимитирован.
Re: Железо сервера БД
Hello, Владимир! Владимир Аксенов wrote: Классические рекомендации: - система - на отдельном винте - TEMP - на отдельном винте - база - на отдельном винте/рейде Время идет, рекомендации меняются. :-) - система - на отдельном винте - temp, база - можно на одном RAID 5 или 10 - бэкапы - на отдельном винте Если RAID5-10 нет, тогда TEMP на отдельном винте нужен только если есть много файлов сортировки, или в базе размером не менее нескольких гиг есть много-много неуникальных индексов (или индексов вообще). как-то так :-) -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re[2]: Железо сервера БД
Привет! >> 1) Система на SSD, своп нафиг. Взять 2 SSD и на втором держать >>отстающую копию системы (как сие сделать на винде - понятия не >>имею). > А смысл тут в SSD? На сервере чтение с системого диска не особо часто. > Вот что делать со свопом? Если система ушла в своп - то где бы он не располагался - настаёт она самая - ж.о.п.а. Поэтому, пусть лучше памяти будет много. У меня есть ещё рекомендации, но это для тру-джедаев - базу в оперативку, а дельта-копии и бэкапы на винт. Будет быстро, но по секрету - если у ОС хватает оперативки закэшировать весь файл базы - то разница будет заметна только на интенсивной записи в БД. >> 4) Оперативки побольше и использовать классик/суперклассик пока не >>перейдёте на тройку :) > Пока специфика нагрузки такова, что достаточно супера. А вот с IO - надо > минимизировать. Тогда кэша страниц побольше, 64-битные сборки хорошо память жрать умеют :0) -- Best regards, Sergeymailto:gebele...@gmail.com
Re: Железо сервера БД
Sergey Mereutsa wrote: Рекомендации от экстремалов: 1) Система на SSD, своп нафиг. Взять 2 SSD и на втором держать отстающую копию системы (как сие сделать на винде - понятия не имею). А смысл тут в SSD? На сервере чтение с системого диска не особо часто. Вот что делать со свопом? 4) Оперативки побольше и использовать классик/суперклассик пока не перейдёте на тройку :) Пока специфика нагрузки такова, что достаточно супера. А вот с IO - надо минимизировать.
Re[2]: Железо сервера БД
Привет! > Классические рекомендации: > - система - на отдельном винте > - TEMP - на отдельном винте > - база - на отдельном винте/рейде > - если на этой машине будут бэкапы/перебэкапы - то для бэкапов > отдельный винт, что бы база и бэкап не лежали на одном винте - кроме > надежности влияет и > на скорость. Рекомендации от экстремалов: 1) Система на SSD, своп нафиг. Взять 2 SSD и на втором держать отстающую копию системы (как сие сделать на винде - понятия не имею). 2) TEMP - 4-8 гигов в оперативке, второй темп - в любом месте. 3) База в зеркале, приоритет кэшу контроллера на чтение 4) Оперативки побольше и использовать классик/суперклассик пока не перейдёте на тройку :) -- Best regards, Sergeymailto:gebele...@gmail.com
Re[2]: Железо сервера БД
Здравствуйте, Alexey. Вы писали 12 июля 2011 г., 17:03:33: > Темп и систему почему бы не одном в целях экономии? Тем более что > большой нагрузки на темп не будет. В целях экономии - можно. Но если цель ускориться - то лучше на разных. В темпе идет сортировка выборки, если она в память не помещается. Ну и что-то еще. У меня в принципе темп тоже не особо юзается, отдельного винта под него нет. -- С уважением, Владимир mailto:fr...@academ.org
Re: Железо сервера БД
Владимир Аксенов wrote: Классические рекомендации: - система - на отдельном винте - TEMP - на отдельном винте Темп и систему почему бы не одном в целях экономии? Тем более что большой нагрузки на темп не будет.
Re: Железо сервера БД
Здравствуйте, Alexey. Вы писали 12 июля 2011 г., 14:02:56: > Планируется поставить простой зеркальный райд под базу. > Вопрос, надо ли ставить отдельный диск для системы, > или тупо можно всё свалить на массив? > Других на нагрузок кроме FB не будет. Классические рекомендации: - система - на отдельном винте - TEMP - на отдельном винте - база - на отдельном винте/рейде - если на этой машине будут бэкапы/перебэкапы - то для бэкапов отдельный винт, что бы база и бэкап не лежали на одном винте - кроме надежности влияет и на скорость. -- С уважением, Владимир mailto:fr...@academ.org
Железо сервера БД
Никогда ещё не занимался комплектованием сервера для FB. Подскажите кое какие моменты. Планируется поставить простой зеркальный райд под базу. Вопрос, надо ли ставить отдельный диск для системы, или тупо можно всё свалить на массив? Других на нагрузок кроме FB не будет. Если памяти в принципе много, то сколько максимум можно отдать в кэш суперсерверу? Или всётаки файловый кэш ОС стправиться со своей задачей тоже эффективно. Можно ли FW отключать или лучше оставить?
