Re: Железо сервера БД
Хм. Есть общие правила выбора. Писалось (выше или ниже) как посмотреть Есть прикладная задача (база) Есть в базе узкие места, которые зависят от логики базы, объема данных и т.д. Прежде чем выбирать железо, набиваем базу тестовыми данными и тогда становиться понятным, что запрос в триггере Select Max(IDDate) from invoicelist where iddate=current_date into Работает быстро пока записей 100. Работает медленно когда записей больше чем 100 Покупаем сервер Select Max(IDDate) from invoicelist where iddate=current_date into работает быстро. Потом записей становиться 100 000 000 И т.д. Я к чему веду, что это искусство решить что менять сервер или логику работы базы. Тестовые данные позволяют такие места выловить и сделать прогноз по работе базы на какой-то период. Количество подключений отъесть какое-то количество ресурсов, но если посмотреть на мой пример, то и одно подключение утомит сервер. Дмитрий
Re: Железо сервера БД
Dmitri Kuzmenko ... С IB вообще интереснее в том плане, что если ему кэша не хватает, то он его увеличивает, это можно отследить, пишет в логи сообщения типа Это есть и в IB6. Только в лог не пишется. -- Хорсун Влад
Re: Железо сервера БД
Hello, Arioch! Arioch wrote: 2) а что скажет Perfmon ? скажет (для меня), как минимум - что происходит с диском. Перфмон я имел в виду как ОДНО ИЗсредств понимания происходящего на сервере. Разумеется, нужно и другие средства использовать. Возможно такие ликбезы нужны не только сисадминам, но и продажникам в серверные конторы типа Аквариуса или etegro. Чтoбы сисадмин мог просто позвонить и заказать сервер под FB, не везде ведь самосбор. так они ж не знают, какие у клиента хотелки. Это, вообще-то, даже не предпродажная консультация. Это реальная консультация на тему - текущее состояние, причины тормозов - перспективы - резервное копирование мы этим и занимаемся, кстати. За деньги :-) с этим уже можно определять бюджет, и брать технику. p.s. даже при выборе ноутбука нужно оценивать массу критериев, о которых клиент может поначалу и не подозревать - вес, работа от батарей, экран, офисные задачи или чего потяжелее, видеокарта (игры, нет), и т.д. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: Железо сервера БД
Hello, A. Truhin! A.Truhin wrote: А о чем тема то была? С начала? О выборе сервера под задачу! И о каком perfmon говорить если сервера еще нет! Вообще то что я написал, меня на данный момент не интересует, я прекрасно на опыте (который сын ошибок трудных) знаю, что нужно мне, под мою задачу. Речь идет о выборе железа / планировании закупок и т.д. я тогда не понял. Вот, мы знаем как работает ФБ на машине 1, 2, 3, с задачами А, Б, В. Мы можем экстраполировать эти данные для выбора железа под конкретную задачу. Если мы не знаем, как работает ФБ и как работает железо вообще, мы ничего не можем выбрать. Мне странно слышать что ты считаешь это не нужным, хотя все остальные производители СУБД уделяют этому очень много времени/ресурсов/информации. я говорю о том, что программист не может жить в отрыве от хотя бы элементарных знаний о дисках, памяти, и куда они расходуются СУБД. Простой статьи как выбрать железо для сервера достаточно не будет. Вон, в игровых журналах и на железных сайтах постоянно появляются статьи по выбору компов для разных задач. Нельзя прочитать одну статью и считать, что теперь можно собирать любой комп под любую задачу. Вообще здесь очень четко видно отличие коммерческих СУБД, от бесплатных, сам продукт может быть очень хорошим, но документация/сопровождение/нагрузочное тестирование :( да фигня это все. Вот есть тест tpc-c, который мы часто используем в своих тестах, и пишем об этом в статьях. Хоть кто-то сам спросил нас дайте тест для проверки на каком-то железе? Нет. Почему? А потому, что нужны системные знания, а не фактография в виде чтобы крутилось быстрее нажмите вот эту кнопку. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: Железо сервера БД
так они ж не знают, какие у клиента хотелки. Это, вообще-то, даже не предпродажная консультация. Это реальная консультация на тему - текущее состояние, причины тормозов - перспективы - резервное копирование мы этим и занимаемся, кстати. За деньги :-) Ты опять говоришь о ситуации апгэйда существующего железа. А речь с начала топика идет о подборе железа под НОВУЮ, БУДУЩУЮ задачу, по крайней мере, автор ни где не сказал, что у него уже задача работает и тормозит. PS. Извини, но иногда создается впечатление, что главное не вникнуть в вопрос, а прямо или косвенно подвести тему к нашим платным консультациям, как у DS к репликации. :)
Re: Железо сервера БД
15.07.2011 20:12, Dmitri Kuzmenko пишет: Hello, A. Truhin! A.Truhin wrote: А о чем тема то была? С начала? О выборе сервера под задачу! И о каком perfmon говорить если сервера еще нет! Вообще то что я написал, меня на данный момент не интересует, я прекрасно на опыте (который сын ошибок трудных) знаю, что нужно мне, под мою задачу. Речь идет о выборе железа / планировании закупок и т.д. я тогда не понял. Вот, мы знаем как работает ФБ на машине 1, 2, 3, с задачами А, Б, В. Мы можем экстраполировать эти данные для выбора железа под конкретную задачу. Если мы не знаем, как работает ФБ и как работает железо вообще, мы ничего не можем выбрать. Вот тут ключевой момент в том, что Вот, мы знаем как работает ФБ на машине 1, 2, 3Мы можем экстраполировать, я например тоже знаю (касаемо моих задач), но вопрос автора, в том и заключается что он не знает. Не у всех есть возможность сравнить работу FB на 5-10-50 серверах разных конфигураций, а закупить железо под будущую задачу на FB, нужно. Мне странно слышать что ты считаешь это не нужным, хотя все остальные производители СУБД уделяют этому очень много времени/ресурсов/информации. я говорю о том, что программист не может жить в отрыве от хотя бы элементарных знаний о дисках, памяти, и куда они расходуются СУБД. Простой статьи как выбрать железо для сервера достаточно не будет. Вон, в игровых журналах и на железных сайтах постоянно появляются статьи по выбору компов для разных задач. Нельзя прочитать одну статью и считать, что теперь можно собирать любой комп под любую задачу. Согласен. Но в разных СУБД требования к ресурсам разные, и сколько ни знай сис. админ. о железе, если он не сталкивался с высоконагруженными FB серверами, он не сможет определить что закупать для будущей задачи. Вообще здесь очень четко видно отличие коммерческих СУБД, от бесплатных, сам продукт может быть очень хорошим, но документация/сопровождение/нагрузочное тестирование :( да фигня это все. Вот есть тест tpc-c, который мы часто используем в своих тестах, и пишем об этом в статьях. Хоть кто-то сам спросил нас дайте тест для проверки на каком-то железе? Нет. Почему? А потому, что нужны системные знания, а не фактография в виде чтобы крутилось быстрее нажмите вот эту кнопку. Может потому, что у кого есть железо, на нем крутится конкретная задача, и там человеку не tpc-c, а кто только собирается закупать железо (как автор) ему еще не на чем крутить тесты.
Re: Железо сервера БД
Hekkim A.Truhin! A.Truhin wrote: Ты опять говоришь о ситуации апгэйда существующего железа. А речь с начала топика идет о подборе железа под НОВУЮ, БУДУЩУЮ задачу, по крайней мере, автор ни где не сказал, что у него уже задача работает и тормозит. ё-мое. как человеку выбрать компьютер, если он ни разу за компьютером не работал? Апгрейд, не апгрейд... Допустим, нужно определить размер памяти для 100 пользователей классика. Мы не сможем определить этот размер, если мы не знаем, сколько памяти жрет один процесс классика под конкретную БД и приложение. Можно только абстрактно заявить, что размер процесса будет 200мб. И то, заявить такое можно только потому, что лично я видел ФБ классик на других серверах. Но человек же на чем-то разрабатывает. Не в блокноте же он пишет код. Значит, есть какой-то компьютер, который можно взять за точку отсчета. PS. Извини, но иногда создается впечатление, что главное не вникнуть в вопрос, я выше и ранее уже объяснил. И на вопрос ответили (и я ответил) уже давно. а прямо или косвенно подвести тему к нашим платным консультациям, как у DS к репликации. :) а не надо стесняться. знания и опыт стоят денег. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: Железо сервера БД
Hello, A.Truhin! A.Truhin wrote: Вот тут ключевой момент в том, что Вот, мы знаем как работает ФБ на машине 1, 2, 3Мы можем экстраполировать, я например тоже знаю (касаемо моих задач), но вопрос автора, в том и заключается что он не знает. Не у всех есть возможность сравнить работу FB на 5-10-50 серверах разных конфигураций, а закупить железо под будущую задачу на FB, нужно. пусть экстраполирует свой десктоп. Все равно невозможно выбрать сервер под задачу так, чтобы сервер был загружен аккурат так, как спрогнозировали. Бывают и неожиданности. К примеру, у меня игровой десктоп. Меряю ФПС. Покупаю новую видеокарту. И практически НИКАКИХ изменений. Оказалось, все упиралось в проц. Согласен. Но в разных СУБД требования к ресурсам разные, и сколько ни знай сис. админ. о железе, если он не сталкивался с высоконагруженными FB серверами, он не сможет определить что закупать для будущей задачи. так нет же конкретных рекомендаций. Все очень приблизительно. Значение имеет только объем памяти и дисковая конфигурация. Может потому, что у кого есть железо, на нем крутится конкретная задача, и там человеку не tpc-c, а кто только собирается закупать железо (как автор) ему еще не на чем крутить тесты. там где крутится конкретная задача, запутить тест очень проблематично, т.к. сервер активно используется, а на тест нужно время. А вот когда собираются закупать новое железо, такая возможность есть, если только сами не закупают по запчастям. В общем, беспредметный разговор. Потому что автор задавал концептуальные вопросы, вообще, а не про конкретные модели дисков, процессоров и так далее. И (мне кажется) ответ на свой вопрос он уже давно получил. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: Железо сервера БД
Hello, A.Truhin! A.Truhin wrote: Вот тут ключевой момент в том, что Вот, мы знаем как работает ФБ на машине 1, 2, 3Мы можем экстраполировать, я например тоже знаю (касаемо моих задач), но вопрос автора, в том и заключается что он не знает. Не у всех есть возможность сравнить работу FB на 5-10-50 серверах разных конфигураций, а закупить железо под будущую задачу на FB, нужно. достаточно двух машин или серверов. И вообще. :-) Возможно, мои представления о процессе чем то искажены, но. (дальше я пишу не про себя, а про абстрактных разработчиков или эксплуататоров) 1. если мы пишем новую задачу, и делаем для себя, то вначале мы должны попробовать как она работает на каком-то компе (сервере, псевдо-сервере, десктопе и т.п.). Если компа не хватает, то смотрим, чего именно, и выбираем новый сервер. 2. если мы обновляем сервер, то смотрим, чего не хватает. 3. если мы консультируем нашего нового клиента, который покупает у нас софт, то мы оцениваем его планируемую загрузку, и сравниваем с железом, которое уже имеется у наших клиентов, и на котором работает наша задача. И выбираем сервер клиенту. В каждом из этих пунктов есть камни преткновения - мы не знаем, как работает наша задача - мы не можем померять нашу задачу ни на чем - мы не знаем, как работает наша задача у наших клиентов вот эти пункты - это реальные проблемы подавляющего большинства компаний, тем или иным образом эксплуатирующих IB/FB. Кто и как их должен решать? Мы статьями на ibase.ru? Или кто-то еще чем-то? -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: Железо сервера БД
Hello, Dmitry! Dmitry Yemanov wrote: пользы нет, только если ты не упрешься вдруг в нехватку памяти на 32-битном супере (2гига). Таких значений, если я правильно помню, достигают люди только с утечками памяти в udf. А что, кеш в 4 гига выставить для большой БД никак? Или типа с большими БД на супере не работают? :-) работают, но заставить супер использовать память трудновато. Я не помню лимит на кэш в ФБ 2.5, в IB его догнали до 131 тыс. страниц, если страница 16к, то это как раз 2 гига. С IB вообще интереснее в том плане, что если ему кэша не хватает, то он его увеличивает, это можно отследить, пишет в логи сообщения типа SRV4 (Server) Wed Apr 21 12:57:27 2010 Database: C:\DATABASE\BASE.GDB Attempting to expand page buffers from 3000 to 3128 SRV4 (Server) Wed Apr 21 12:57:27 2010 Database: C:\DATABASE\BASE.GDB Page buffer expansion complete и понять, какой необходимый минимум нужен суперу. Так вот, на одной базе в 30 гиг и ~200 пользователей кэша хватило в 16000 страниц. Еще, понятно, памяти под сортировку можно поднять, тогда с 131к страниц кэша можно и превысить 2 гига -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: Железо сервера БД
Hello, Alexey! Alexey Popov wrote: С админов толку мало, т.к. они широкого профиля. Тюнить FB всё равно разработчику. У нас просто пока не было столь высоких нагрузок, но сейчас стоит вопрос об установке нового сервера. тюнить ФБ можно мало куда. И я говорю про конфигурации железа для СУБД вообще. ФБ - одна из множества других СУБД. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: Железо сервера БД
Hello, A.Truhin! A.Truhin wrote: возникает вопрос: сколько и каких ресурсов нужно FB, для определенного профиля работы. у кого этот вопрос возникает - у сферического SQL-программиста? Например, вопрос выбора классика или супера ФБ разжеван в достаточно многих местах. Про память - взял да запустил, посмотрел Диспетчером задач или в ps. Много ума для этого надо? Т.е. вложить больше денег: в процессор, hdd, raid контроллер. В диск. СУБД это диск, разве это не очевидно? И вот здесь, полный информационный вакуум, как распределяется нагрузка по железу для FB при сценариях WEB бд, OLTP систем и т.д, при разном количестве пользователей. при чем тут ФБ??? Какие сценарии??? Я допускаю наличие только одного вопроса - сколько классику надо ядер при каком количестве пользователей. Могу ответить сразу - 300-400 - до 24 ядер. 8-12 ядер - 100 пользователей. Как-то так. Сами сталкивались с этим, и если для oracle, mssql есть и рекомендации разработчиков, и готовые сервера оптимизированные под бд, и тесты, то для Firebird не нашли ни чего. Также последнее время на sql.ru постоянно возникают темы по инсталляции FB для нескольких сотен коннектов, и каждый из ТС начинает заново проходить все грабли по выбору, настройке ОС, настройке FB. грабли - просто незнание элементарных вещей. Чтобы ездить на БелАЗе, нужно вначале обучиться. :-) Я это к тому, что на вашем сайте великолепная подборка материалов для начала освоения FB. Но люди растут, базы растут, не помешали бы статьи/тесты/рекомендации по более серьезным вопросам. а деньги откуда брать? :-) Вообще у меня двоякое ощущение. С одной стороны, ликбез необходим, но с другой стороны, почему за мой счет? Например, почему я должен на сайте держать статью, в которой объяснялось бы, как использовать PerfMon? -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: Железо сервера БД
Dmitri Kuzmenko wrote: тюнить ФБ можно мало куда. И я говорю про конфигурации железа для СУБД вообще. ФБ - одна из множества других СУБД. Сейчас прибегут из множества других СУБД и будут вещать про партиционирование и лог транзакций. Железо для СУБД для среднестатитического админа ни о чём не говорит - надо хоть как то представлять как работает внутри сервер. А у FB тонкости ещё связанные с типом: SS/CS.
Re: Железо сервера БД
В письме от Thu, 14 Jul 2011 14:21:15 +0400, Dmitri Kuzmenko k...@ibase.ru сообщал: Могу ответить сразу - 300-400 - до 24 ядер. 8-12 ядер - 100 пользователей. Как-то так. ... Например, почему я должен на сайте держать статью, в которой объяснялось бы, как использовать PerfMon? 1) можно держать ссылки на рекомендованные статья по Perfmon или на список вопросов к Perfmon на котороые надо найти ответ. Хотя конечно лежать они должны не на ibase.ru, а на firebirdsql.org 2) а что скажет Perfmon ? Пример с птолка, допустим на -ядерном сервере крутятся 30 пользователей. Тормозит уже так, что выделили денег на новый. Вообще-то тормозит давно - но раньше терпели. Не хватает уже всего, и дисков и памяти и проца. Нужен сервер на 5 лет вперед, на те самые 100 пользователей. И чем Perfmon поможет в ситуации, когда провести тест не на чем - новый сервер ещё не купили, равного по мощности в компании нет, и не с кем - 100 пользователей и соотв. количества данных в БД пока тоже нет. Хотя это можно в той или иной степени сымитировать программно, конечно. Возможно такие ликбезы нужны не только сисадминам, но и продажникам в серверные конторы типа Аквариуса или etegro. Чтoбы сисадмин мог просто позвонить и заказать сервер под FB, не везде ведь самосбор. -- Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/
Re: Железо сервера БД
14.07.2011 20:21, Dmitri Kuzmenko пишет: Hello, A.Truhin! A.Truhin wrote: возникает вопрос: сколько и каких ресурсов нужно FB, для определенного профиля работы. у кого этот вопрос возникает - у сферического SQL-программиста? Например, вопрос выбора классика или супера ФБ разжеван в достаточно многих местах. Про память - взял да запустил, посмотрел Диспетчером задач или в ps. Много ума для этого надо? А о чем тема то была? С начала? О выборе сервера под задачу! И о каком perfmon говорить если сервера еще нет! Вообще то что я написал, меня на данный момент не интересует, я прекрасно на опыте (который сын ошибок трудных) знаю, что нужно мне, под мою задачу. Речь идет о выборе железа / планировании закупок и т.д. Мне странно слышать что ты считаешь это не нужным, хотя все остальные производители СУБД уделяют этому очень много времени/ресурсов/информации. Вообще здесь очень четко видно отличие коммерческих СУБД, от бесплатных, сам продукт может быть очень хорошим, но документация/сопровождение/нагрузочное тестирование :(
Re[2]: Железо сервера БД
Привет! Странно, почему никто не указывает варианта Ось+temp на обычный винт(ы), а под базу - SSD. Вполне себе бюджетный и скоростной вариант. Потому, что интенсивная работа с SSD означает базу Шрёдингера - рано или поздно умрёт, но когда именно - узнаешь в неопределённый момент времени. И будет очень неприятно, если узнаешь об этом за пару часов до начала отпуска. Хотя да, риальные поцаны могут себе позволить очень шустрое хранилище от Sun/Oracle на 2 Тб, сплошь на скоростной памяти. Я считал, кирпич из серебра аналогичного веса стоит дешевле. -- Best regards, Sergeymailto:gebele...@gmail.com
Re: Железо сервера БД
Dmitry Yemanov wrote: А что, кеш в 4 гига выставить для большой БД никак? А интересно, кто пробовал такое делать?
Re: Re[2]: Железо сервера БД
Потому, что интенсивная работа с SSD означает базу Шрёдингера - рано или поздно умрёт, но когда именно - узнаешь в неопределённый момент времени. И будет очень неприятно, если узнаешь об этом за пару часов до начала отпуска. Ну это ещё вопрос, конечно, что умрёт раньше, ssd или винт. Да и умирают они не внезапно, просто отдельные блоки становятся рид-онли. В принципе, если бэкапов недостаточно, и нужна надёжность 24/7, то можно и мониторинг SMARTа прикрутить, чтоб знать, когда придёт пора менять ssd. Опять же, повторюсь, вариант, если хочется быстро и недорого. Такой вариант уже в течение года эксплуатируем, на вполне рядовом Kingston SNVP325-S2B/128GB, записей порядка 2ГБайт в сутки на него, полёт нормальный, тьфу-тьфу :) Ну а прирост в производительности порядка 3-5 раз, особенно заметно при нескольких тяжелых запросах, никаких проседаний. Сравниваю, правда, не с raid, с обычным жестким диском трехлетней давности. -- С уважением, Короткий Олег koro...@gmail.com icq#168812289
Re[2]: Железо сервера БД
Привет! А что, кеш в 4 гига выставить для большой БД никак? А интересно, кто пробовал такое делать? Я, когда суперклассик ковырял. Работало, но сам суперклассик тогда сырой был, пришлось ставить классик. Сейчас потестить просто негде - всё в полёте :) -- Best regards, Sergeymailto:gebele...@gmail.com
Re: Железо сервера БД
Sergey Mereutsa wrote: А что, кеш в 4 гига выставить для большой БД никак? А интересно, кто пробовал такое делать? Я, когда суперклассик ковырял. Работало, но сам суперклассик тогда сырой был, пришлось ставить классик. Вопрос то про суперсервер был. Суперклассик это совсем другое.
Re: Железо сервера БД
В письме от Tue, 12 Jul 2011 20:15:11 +0400, Dmitri Kuzmenko k...@ibase.ru сообщал: уже давно даже для десктопов МС рекомендует машинки с ДВУМЯ дисками. Один система и софт, другой - работа и данные. O'RLY ? а почему тогда \Users до сих пор ставится на c:\ и чёрт с ним с дефолтом - но даже не предлагает инсталлятор его её куда-нибудь поместить... -- Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/
Железо сервера БД
Никогда ещё не занимался комплектованием сервера для FB. Подскажите кое какие моменты. Планируется поставить простой зеркальный райд под базу. Вопрос, надо ли ставить отдельный диск для системы, или тупо можно всё свалить на массив? Других на нагрузок кроме FB не будет. Если памяти в принципе много, то сколько максимум можно отдать в кэш суперсерверу? Или всётаки файловый кэш ОС стправиться со своей задачей тоже эффективно. Можно ли FW отключать или лучше оставить?
Re: Железо сервера БД
Владимир Аксенов wrote: Классические рекомендации: - система - на отдельном винте - TEMP - на отдельном винте Темп и систему почему бы не одном в целях экономии? Тем более что большой нагрузки на темп не будет.
Re[2]: Железо сервера БД
Здравствуйте, Alexey. Вы писали 12 июля 2011 г., 17:03:33: Темп и систему почему бы не одном в целях экономии? Тем более что большой нагрузки на темп не будет. В целях экономии - можно. Но если цель ускориться - то лучше на разных. В темпе идет сортировка выборки, если она в память не помещается. Ну и что-то еще. У меня в принципе темп тоже не особо юзается, отдельного винта под него нет. -- С уважением, Владимир mailto:fr...@academ.org
Re[2]: Железо сервера БД
Привет! Классические рекомендации: - система - на отдельном винте - TEMP - на отдельном винте - база - на отдельном винте/рейде - если на этой машине будут бэкапы/перебэкапы - то для бэкапов отдельный винт, что бы база и бэкап не лежали на одном винте - кроме надежности влияет и на скорость. Рекомендации от экстремалов: 1) Система на SSD, своп нафиг. Взять 2 SSD и на втором держать отстающую копию системы (как сие сделать на винде - понятия не имею). 2) TEMP - 4-8 гигов в оперативке, второй темп - в любом месте. 3) База в зеркале, приоритет кэшу контроллера на чтение 4) Оперативки побольше и использовать классик/суперклассик пока не перейдёте на тройку :) -- Best regards, Sergeymailto:gebele...@gmail.com
Re: Железо сервера БД
Sergey Mereutsa wrote: Рекомендации от экстремалов: 1) Система на SSD, своп нафиг. Взять 2 SSD и на втором держать отстающую копию системы (как сие сделать на винде - понятия не имею). А смысл тут в SSD? На сервере чтение с системого диска не особо часто. Вот что делать со свопом? 4) Оперативки побольше и использовать классик/суперклассик пока не перейдёте на тройку :) Пока специфика нагрузки такова, что достаточно супера. А вот с IO - надо минимизировать.
Re[2]: Железо сервера БД
Привет! 1) Система на SSD, своп нафиг. Взять 2 SSD и на втором держать отстающую копию системы (как сие сделать на винде - понятия не имею). А смысл тут в SSD? На сервере чтение с системого диска не особо часто. Вот что делать со свопом? Если система ушла в своп - то где бы он не располагался - настаёт она самая - ж.о.п.а. Поэтому, пусть лучше памяти будет много. У меня есть ещё рекомендации, но это для тру-джедаев - базу в оперативку, а дельта-копии и бэкапы на винт. Будет быстро, но по секрету - если у ОС хватает оперативки закэшировать весь файл базы - то разница будет заметна только на интенсивной записи в БД. 4) Оперативки побольше и использовать классик/суперклассик пока не перейдёте на тройку :) Пока специфика нагрузки такова, что достаточно супера. А вот с IO - надо минимизировать. Тогда кэша страниц побольше, 64-битные сборки хорошо память жрать умеют :0) -- Best regards, Sergeymailto:gebele...@gmail.com
Re: Железо сервера БД
Hello, Владимир! Владимир Аксенов wrote: Классические рекомендации: - система - на отдельном винте - TEMP - на отдельном винте - база - на отдельном винте/рейде Время идет, рекомендации меняются. :-) - система - на отдельном винте - temp, база - можно на одном RAID 5 или 10 - бэкапы - на отдельном винте Если RAID5-10 нет, тогда TEMP на отдельном винте нужен только если есть много файлов сортировки, или в базе размером не менее нескольких гиг есть много-много неуникальных индексов (или индексов вообще). как-то так :-) -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: Железо сервера БД
Sergey Mereutsa wrote: Если система ушла в своп - то где бы он не располагался - настаёт она самая - ж.о.п.а. Поэтому, пусть лучше памяти будет много. Своп вроде бы всегда используется виндой для своих нужд. Тогда кэша страниц побольше, 64-битные сборки хорошо память жрать умеют :0) Кстати, есть какая польза от 64-битного супера? Вроде максимальный размер кэша как то лимитирован.
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: Железо сервера БД
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: Своп вроде бы всегда используется виндой для своих нужд. не слушай его про без свопа. Кстати, есть какая польза от 64-битного супера? Вроде максимальный размер кэша как то лимитирован. пользы нет, только если ты не упрешься вдруг в нехватку памяти на 32-битном супере (2гига). Таких значений, если я правильно помню, достигают люди только с утечками памяти в udf. В любом случае, на 64битной ОС заменить 32битный ФБ на 64битный - дело 30-ти секунд. Вот поменять разрядность ОС - это уже проблематично. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: Железо сервера БД
Hello, Alexey! Alexey Popov wrote: Никогда ещё не занимался комплектованием сервера для FB. Подскажите кое какие моменты. можно я риторический вопрос задам, в пространство? Поскольку ситуация с выбором железа у людей, работающих с ФБ, просто ну никуда, не могу понять. Неужели эти люди никогда не интересовались скоростью работы диска? Не запускали HDTune? Не читали никаких обзоров про сравнение дисков, рэйдов, не способны понять выгоду от разделения IO, и т.д.? Особенно феерично сталкиваться с таким незнанием у админов. [тут был еще абзац, но я его удалил :-) ] -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: Железо сервера БД
Dmitri Kuzmenko wrote: можно я риторический вопрос задам, в пространство? Поскольку ситуация с выбором железа у людей, работающих с ФБ, просто ну никуда, не могу понять. Неужели эти люди никогда не интересовались скоростью работы диска? Не запускали HDTune? Не читали никаких обзоров про сравнение дисков, рэйдов, не способны понять выгоду от разделения IO, и т.д.? Особенно феерично сталкиваться с таким незнанием у админов. С админов толку мало, т.к. они широкого профиля. Тюнить FB всё равно разработчику. У нас просто пока не было столь высоких нагрузок, но сейчас стоит вопрос об установке нового сервера.
Re: Железо сервера БД
Dmitri Kuzmenko wrote: Время идет, рекомендации меняются. :-) - система - на отдельном винте - temp, база - можно на одном RAID 5 или 10 - бэкапы - на отдельном винте В целях экономии можно бэкап наверное делать на системный винт, а оттуда уже сливать по сети в надёжное место.
Re: Железо сервера БД
Dmitri Kuzmenko wrote: Можно ли FW отключать или лучше оставить? отключать можно, если это ФБ 2.1 и выше (см. firebird.conf) Костыль однако. Но тем не менее... или если стоит raid с батарейкой. Но на raid с батарейкой может оказаться все равно, Fw=on или off. зависит от крутизны raid. Тут вопрос больше не в питании, а логических сбоях ОС, которые приведут к неконсистентности записи.
Re: Железо сервера БД
12.07.2011 20:22, Dmitri Kuzmenko пишет: Кстати, есть какая польза от 64-битного супера? Вроде максимальный размер кэша как то лимитирован. пользы нет, только если ты не упрешься вдруг в нехватку памяти на 32-битном супере (2гига). Таких значений, если я правильно помню, достигают люди только с утечками памяти в udf. А что, кеш в 4 гига выставить для большой БД никак? Или типа с большими БД на супере не работают? :-) -- Дмитрий Еманов
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[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: Железо сервера БД
13.07.2011 2:28, Dmitri Kuzmenko пишет: можно я риторический вопрос задам, в пространство? Поскольку ситуация с выбором железа у людей, работающих с ФБ, просто ну никуда, не могу понять. Неужели эти люди никогда не интересовались скоростью работы диска? Не запускали HDTune? Не читали никаких обзоров про сравнение дисков, рэйдов, не способны понять выгоду от разделения IO, и т.д.? Особенно феерично сталкиваться с таким незнанием у админов. [тут был еще абзац, но я его удалил :-) ] А вот тут можно спорить, ведь если бюджет неограничен - понятно, ставь самые быстрые диски и камень по мощнее. Но речь идет о ограниченном бюджете, и сколько бы люди не читали обзоров (Не запускали HDTune), возникает вопрос: сколько и каких ресурсов нужно FB, для определенного профиля работы. Т.е. вложить больше денег: в процессор, hdd, raid контроллер. И вот здесь, полный информационный вакуум, как распределяется нагрузка по железу для FB при сценариях WEB бд, OLTP систем и т.д, при разном количестве пользователей. Сами сталкивались с этим, и если для oracle, mssql есть и рекомендации разработчиков, и готовые сервера оптимизированные под бд, и тесты, то для Firebird не нашли ни чего. Также последнее время на sql.ru постоянно возникают темы по инсталляции FB для нескольких сотен коннектов, и каждый из ТС начинает заново проходить все грабли по выбору, настройке ОС, настройке FB. Я это к тому, что на вашем сайте великолепная подборка материалов для начала освоения FB. Но люди растут, базы растут, не помешали бы статьи/тесты/рекомендации по более серьезным вопросам.
