Сервер для MS SourceSafe

[SergOK]

Мне интересно выслушать мнения по поводу конфигурации сервера для Microsoft SourceSafe.
На сервере планируется хранить 20 баз. К каждой из баз может теоретически подключаться до 20 пользователей. (Это максимальная нагрузка). Обычно 3-5 пользователей на базу, и то не на каждую.

[gs]

Прошу прощения за мою темноту, но что это за зверь такой?
Причем скорее интересует характер нагрузки - как грузятся процы, память, тип трафика (линейный, хаотичный, примерный размер передаваемых блоков). Как часто клиенты будут в базу лазить и какого рода данные получать в ответ.

[SergOK]

Прошу прощения за мою темноту, но что это за зверь такой?
Причем скорее интересует характер нагрузки - как грузятся процы, память, тип трафика (линейный, хаотичный, примерный размер передаваемых блоков). Как часто клиенты будут в базу лазить и какого рода данные получать в ответ.

Это офигительно тупой и безобразный зверь.
Представляет из себя офигительно большой набор достаточно небольших файлов. В нашем случае на каждую базу примерно приходится 40 000 файлов общим объемом 600 Мб.
Процы обычно не грузятся. Основная нагрузка - дисковая подсистема.
Для клиентов имеется специальная программка которая позволяет лазать по базе и смотреть (получать) файлы. Так вот сама процедура просмотра бывает очень сильно тормозит.

[a_shats]

Можно и мои 5 копеек ?
Я тоже не в курсе, что це за зверь , но, по Вашим данным о нагрузке, попробую прикинуть:
1. Процессоры: по Вашим данным, нагрузка на них невелика. Сталбыть, крутыми можно не заморачиваться. Но: по причине наличия до 20 пользователей, лучше иметь их 2, что-то типа PIIIS-1133. отсюда - уже можно прикинуть мать.
2. Память: у Вас - 20 баз по 300 Мб, итого около 6 Гб. Имхо, нужно 4 Гб оперативки. Мамки SDS2/SAI2 это позволяют запросто.
3. Дисковая: ну, тут RAID однозначно. Кстати: какие запросы наиболее характерны для этих Ваших баз: чтение, запись или часто выполняется и то, и другое ? С этим можно будет прикинуть уровень, количество каналов и кэша RAID и количество необходимых винтов. Кстати, еще: каковы требования/терпимость к времени простоя ? Тоже повлияет на вышеуказанный параметр, к тому же определит необходимость Hotswap корзин. Хотя, имхо, если есть возможность купить нормальный сервер, лучше сразу брать с Hotswap.
4. Бэкап: при Ваших объемах лучше стример. Не менее, чем на 20/40 Гб. Имхо .

[SergOK]

Можно и мои 5 копеек ?

велком

1. Процессоры: по Вашим данным, нагрузка на них невелика. Сталбыть, крутыми можно не заморачиваться. Но: по причине наличия до 20 пользователей, лучше иметь их 2, что-то типа PIIIS-1133. отсюда - уже можно прикинуть мать.

а типа как количество ползователей согласуется с количеством процессоров? Да хоть 30 пользователей будут насиловать винт. Камень-то наверное сильно не по роляет?

2. Память: у Вас - 20 баз по 300 Мб, итого около 6 Гб. Имхо, нужно 4 Гб оперативки.

Это дисковая память. И всю ее в кеш запихать просто нереально. Да и нет смысла наверное.

3. Дисковая: ну, тут RAID однозначно.

кто-бы спорил

Кстати: какие запросы наиболее характерны для этих Ваших баз: чтение, запись или часто выполняется и то, и другое ?

именно и то и другое. Я наверное неправильно употребил слово "базы". Под базой понимается _очень_ большой объем достаточно небольших файлов. Нагрузка, в основном, - это чтение.

[gs]

Нагрузка наиболее гнусная - заставляет винты шуршать головами. Процессора наверно и одного хватит вполне. Только лучше с PIII уже не заморачиваться (король умер). Памяти скорее всего много не надо - посмотрите по мониторингу сколько реально ест Ваша прога. Если тормозит смотрелка, то, видимо, она не умеет кэшировать индексы, а лазит каждый раз на диски. Если эта таблица невелика, можно попробовать кэша на контроллере прибавить (это не так дорого, но поможет ли - зависит от софта).
А вообще-то общая рекомендация при работе с маленьки блоками данных - побольше дисков, желательно быстрых и, при возможности, RAID0+1. Естественно, если Ваши прога умеет одновременно несколько запросов отрабатывать.
например так: P4-2.0, 512-1ГБ РАМ, А170-32 (попробуйте воткнуть 128, может помочь, но не наверняка), 4х18ГБ (при возможности 15000).
В принципе навернуть машину можно круче, но затраты будут не пропорциональны эффекту.

[Курдиков Сергей]

Полностью согласен с коллегой GS.

[a_shats]

Да хоть 30 пользователей будут насиловать винт. Камень-то наверное сильно не по роляет?

Фиг с ним, ставьте РРro 150-ый
У Вас сие чудо (SourceSafe) на сервере че-нить помимо хранения файлов делает еще ? Типа переиндексации/проверки/восстановления и т.п. А помимо SourceSafe еще что-нить на сервере вообще выполняется ?
Еще вопрос: раз есть информация в таком объеме, значит по ней выполняются поиск и выборка. Как они в Вашем случае реализованы: как БД в файловом варианте (клиент тянет все к себе и делает все на себе) или в клиент-серверном ? Или вообще - простой тупой поиск что-нить типа Indexing Service'ом ?
Это - в сторону определения необходимости в процессорной моще и количестве.
Да и потом - 100-150 баксов в общей стоимости сервера порядка 3500-4500 баксов просто не почувствуются, а польза может быть велика.

Это дисковая память. И всю ее в кеш запихать просто нереально. Да и нет смысла наверное.

Всю - нереально и не нужно Наиболее эффективно - кэшировать как минимум "короткие" справочники и индексы. А индексы имеют тоже нехилый объем.
Конечно, файловый кэш ОС не станет разбираться, где что, но - то, что указано выше - обычно наиболее часто читаемые данные.
Но: я считал 50% от объема базы + 256 Мб под ОС + все остальное под запас - базы то у Вас растут ? Или нет ?

именно и то и другое. Я наверное неправильно употребил слово "базы". Под базой понимается _очень_ большой объем достаточно небольших файлов. Нагрузка, в основном, - это чтение.

Чудненько . Совмещаем высокую производительность на чтение+отказоустойчивость, получаем по минимуму - RAID 1 (зеркало). Так?
6 Гб базы... Так. Емкость винтов под базу, таким образом выходит, достаточно пары по 18 Гб в зеркале. Лучше, естественно, в хотсвап-корзинке - тогда не нужно будет останавливать сервер в случае чего (да и вообще: корпуса по крайней мере от Интел с HSRP имеют помимо корзинки еще и hot-swap блоки питания, и вентиляторы, и т.д.).
Второе: Совмещать систему и базы хотим ? Если да, то можно обойтись вышеописанным зеркалом. Если нет - нужно еще одно зеркало - под систему.
С точки зрения производительности второй вариант предпочтительнее.
Последнее: все-таки что-то для бэкапа вставлять будем ?
Что теперь вытанцовывается ?
Примерно следующее:
2xPIIIS-1133/Intel SDS2/4 (4x1 Gb) ECC Registered Intel Qualified RAM
Вариант с Hotswap и выделенной на отдельный массив системой:
Hudson II SC5100 HSRP/Mylex A170 64 Mb/4x HDD U160 SCA
По минимуму:
Hudson II SC5100 Base/Intel SRCU31/2xHDD U160
Ну и девайс для быкапа - вопрос см. выше.
И последний вопрос: если хотим сие в виде башни, то имхо, стоит остановиться на указанном варианте. А если хотите rackmount(для установки в шкаф/стойку)... Пишите, подберем.
Все вышенаписанное есть имхо.

[SergOK]

Ну в принципе все понятно.
Просто я поинтересовался наедясь может что-то новое присоветуют.
Стоит у нас все это на HP LH3000r RAID5 из 3 винтов.
На том же канале integrated NetRAID сидит еще пара винтов.
Памяти на машинке 768Мб
Помимо вот этой вот фаловой помойки (MS SourceSafe) пришлось поставить MS SQL 7. И вот у пользователей возникли проблемы с доступом. Просто все тормозит...

[CyberDrake]

Маленькое замечание для a_shats:

Совмещаем высокую производительность на чтение+отказоустойчивость, получаем по минимуму - RAID 1 (зеркало). Так?

ну отказоустойчивость мы здесь получим, а вот на счет скорости, сомневаюсь (Параллельности чтения/записи в RAID1 кот наплакал - вся скорость ограничивается скоростью одного винта)
так что на базу лучше поставить RAID 5 или 0+1 (в зависимости от соотношения чтение/запись), ну а на систему вполне можно и зеркало поставить

А ежели делать дешево и сердито, то можно даже не SDS2+Hudson, а Supermicro P3TDLE + InWinQ500 или R3000

[gs]

Ну в принципе все понятно.
Помимо вот этой вот фаловой помойки (MS SourceSafe) пришлось поставить MS SQL 7. И вот у пользователей возникли проблемы с доступом. Просто все тормозит...

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

[a_shats]

ну отказоустойчивость мы здесь получим, а вот на счет скорости, сомневаюсь (Параллельности чтения/записи в RAID1 кот наплакал - вся скорость ограничивается скоростью одного винта)

Минуточку, минуточку
На чтение аппаратные RAID в RAID1 умеют параллелить запросы к винтам.
На запись - да, вопросов нет, пишется разом на 2 одно и то же. Но ведь есть кэш RAID - и при наличии кучи мелких запросов и Write Back усе будет ОК.
Т.е. по минимуму как раз лучше мой вариант

так что на базу лучше поставить RAID 5 или 0+1 (в зависимости от соотношения чтение/запись), ну а на систему вполне можно и зеркало поставить

А чем RAID5 на чтение быстрее RAID1 ? Имхо, даже медленнее.

А ежели делать дешево и сердито, то можно даже не SDS2+Hudson, а Supermicro P3TDLE + InWinQ500 или R3000

Можно на Р4 за 500 баксов - предлагали уже
А серьезно - в серверах это понятие - "дешево и сердито" - имхо, неприемлемо.
Вдогонку:
Сорри, не заметил про MSSQL сразу.
Дело в том, что нагрузка на, по сути, файловый сервер и сервер под SQL в принципе различна по своему характеру. Файловый сервер - массовое чтение/запись (в течение раб. дня обычно мелкое, но есть пики - в начале, конце и перед/после обеда ). SQL(на задачах OLTP, т.е. сбора инф-ции, не аналитики) - чтение мелкими блоками "вразброс", практически без пиков - и нагрузка на проц/память (обычно в районе 10-50%). И не стоит эти вещи совмещать - либо совмещать надо (в пределах одного сервера) на дисковых подсистемах, оптимизированных именно под такие типы нагрузки. Т.е. для ФС с преобладающим чтением эффективнее аппаратное зеркало, для SQL - RAID5 или 0+1.

[a_shats]

Нагрузка наиболее гнусная - заставляет винты шуршать головами. Процессора наверно и одного хватит вполне. Только лучше с PIII уже не заморачиваться (король умер).
...
P4-2.0, 512-1ГБ РАМ, А170-32 (попробуйте воткнуть 128, может помочь, но не наверняка), 4х18ГБ (при возможности 15000).

Нет!!! Только не Р4!!!!
Если уж уходить от РIII (рановато, думаю ), то - не меньше чем Xeon.
И не говорите пожалуйста о том, что Р4 512 К и Xeon DP - одно и то же (все ж таки удалось людям погонять на том двухксеоннике MSSQL 7 - люди говорят, что в включенным гипертридингом очень даже неплохо (и сравнивать им есть с чем - рядом стоит полумертвый от нагрузок Р4 1,8 Ггц - который тоже не Вилламетт).
А на Р4 - хм... Большинство наших клиентов, приобретающих новые сервера под БД - и SQL, и файловые(с терминалкой вкупе) как раз с них, родимых, и переходят на "нормальные" сервера.
И потом, 15К винты на такой "совсем минимальный" адаптер RAID (тем более по 4) сажать, имхо, не стоит - не хватит его производительности - и кэш 128 может не помочь. Тогда уж 352-й.

[gs]

Что касается распараллеливания операций чтения на рэйд1, то этот прикол давно гуляет по сети. На практике это не так. При линейном чтении скорость примерно равна скорости одного винта, также как и при записи (по крайней мере для майлекса). Могу привести логическое объяснение, но это много писанины - но можете поверить, сам тестировал.
Рэйд5 намного быстрее рэйда1 практически во всех случаях (опять-таки практика).
Не верьте теории - это просто голые математические алгоритмы, которые работают на реальных процессорах с весьма хилой производительностью. К тому же все зависит от конкретного программиста фирмваре. (Да и алгоритмы эти просты только на бумаге, при более детальном рассмотрении вмешивается куча разных факторов, которые в популярных статьях обычно не учитывают)

[gs]

И потом, 15К винты на такой "совсем минимальный" адаптер RAID (тем более по 4) сажать, имхо, не стоит - не хватит его производительности - и кэш 128 может не помочь. Тогда уж 352-й.

Производительность 170 и 352 при равном числе винтов и случайных операциях РАВНА!!! 352 отличается только шиной PCI64-33, вторым каналом и возможность поставить батарейку. Он быстрее 170 только там, где ограничивающим фактором является шина - т.е. линейное чтение нескольких потоков. Ну и естественно, винтов можно повесить больше, но это в данном случае не грозит.

На случайных операциях производительность зависит на 90% зависит от скорости винтов. Диск способен отработать 200-300 коротких IOps, контроллер 5000-7000 (что достигается либо при большом числе винтов, либо при кэшированных операциях). Так что скорости 170 будет более чем достаточно.