GallemarКак сделать вывод?а чем еще отличаются серваки, помимо наличия/отсутствия SSD ?

GallemarТаблоидпропущено...
а чем еще отличаются серваки, помимо наличия/отсутствия SSD ?
отличаются по процам и памяти, на тестовом меньше. Могу скинуть где что есть.Тогда не факт, что сравнение окажется корректным.

ЗЫ. Какая цель замены дискового массива ? Если там вопрос произв-сти приложения, то замена железа - это должен быть последний метод, когда уже ничего не помогает.

GallemarТаблоидпропущено...
Тогда не факт, что сравнение окажется корректным.хм. Вот в чем и проблема. Надо сравнить SSD на чтение/запись,но как в таких условиях я хзЕсли только прогнать тест на SSD, а затем на этой же машине - на "обычном" дисковом массиве.

Gallemarрастет размер БД и кол-во пользователей (220Гб, 280 коннектов) и будет расти дальше. Рано или поздно но ресурсов железа перестанет хватить,особенно это сильно чувствуется на работе дисков,память и проц не так критичны. Вот и хочется понять - ставя более производительные диски мы сможем увеличить время работы сервера до окончания ресурсов железа?Что именно "чувствуется на работе ДИСКОВ" ? Ты базу копируешь бесконца, что ле ? (да, я знаю, что у тебя там 2.5 + энбекап; ну так ты поднял наконец репликатор или нет ??)

Gallemar,

ну-ка скажи мне прямо, по пролетарски: ты user-трейс врубал на своей системе ? запросы тормознутые выуживал из неё, пытался обсудить их с разрабами ?
Они ведь так и останутся на самом-супер-пупер-новом дисковом SSD, никуда не денутся...

o_v_aТаблоидЧто именно "чувствуется на работе ДИСКОВ" ? Ты базу копируешь бесконца, что ле ? Да вот тоже не ясно. 200 с гаком гектар кто-то постоянно перелопачивает от начала и до упора?nbackup перелопачивает. ЛЮБОГО уровня, не только нулевого. Это в 3.0 лишь сделано, что он быстро находит только изменённые страницы.

GallemarЯ о том что производительность зависит больше от скорости дисков,а не памяти/процессоров,их у нас вообще хоть ж... ешь :)Нет. Произв-сть запроса, который во where-условии содержит [not] in( select ... ) или вообще агрегат какой-нибудь, никакими дисками не выправишь. Запрос с full join'ом в ФБ вообще мертвяк, его надо всегда менять на union + group by. Триггер, регулярно ходящий в mon$ за IP адресом (хотя его можно получить через встроенную rdb$get_context) - тоже источник Мирового зла. Ну и т.п.
Слушай своих юзеров! Обращай внимание на их сигналы о тормозах, записывай время и что они делают в проге, затем пробуй сам воспроизвести это (уж свой-то id-коннекта ты точно будешь знать ==> делай это с трейсом).
Короче: ищи тормознутые запросы. Твоя прога стопудово их содержит, ибо она - БОЛЬШАЯ и её разрабы, скорее всего, никогда её не испытывали под нагрузкой.

GallemarПо производительности в данный момент проблем нет - запросы в нормеПардон, не увидел этот ответ.
Gallemarбаза растет и растет кол-во пользователей(ПО автоматизации торговли, магазинов всё больше и больше). Сейчас при 45 магазинах она 220 гигов. К следующему году их будет 80. Когда я упрусь в потолок по ресурсам?Важнее число юзеров, которые одновременно что-то молотят, а не размер базы. Ты запускал select count(*)-1 from mon$statements where mon$state=1 ?

GallemarТы запускал select count(*)-1 from mon$statements where mon$state=1 ?
9[/quot]Ну, и чего тогда припёрло менять диски ? :-)

BTW: из твоих 220 Гб - что там больше всего места занимает ? Не аудит ли часом какой-нибудь ?