Итак, как не смешно бы это звучало, но, есть 7.7 комплексная, база SQL порядка 45 гигабайт, подключений к базе около 45-50, крутится это все на Windows2003 Server + SQL Server 2000, аппаратно самое смешное Core2Duo E8200 + 4Gb RAM + SSD (система) + RAID 0 SAS 2*HHD 300Gb (бэкапы наше все), (0 был выбран для ускорения дисковой подсистемы) на старом контроллере LSI. Вопрос стоит ли обновлять аппаратную часть? Работа становится не комфортной. По мелочи используются прямые запросы.

Та не, зачем оно нам нужнО? Работает и не трогай

(0) случаем не тут http://zenonline.ru?

У нас примерно то же самое. Нормально работает. Особенно с прямыми запросами.

Вот только raid0 у вас зря - лучше сделайте raid1, ибо в семерке по сети вовсе не скорость записи на диск узкое место

(2) не понял к чему это.

(4) так у 0-вки скорость работы с диском быстрей чем в 1-ке

(5) не в этой конторе еще клюшки починяешь?

(7) не

(7) а там тоже клюшки?

(9) а хз

+(10) когда-то были точно

(6) С чего бы вдруг быстрее?

прогнать на sql-сервере "широко известный в узких кругах ограниченных людей" "тест им. vde69".
посмотреть на результаты.

(12) сторно. Спутал с райд-1.

(12) Performance
Writes
RAID 0 offers very fast write times because the data is split and written to several disks in parallel. Writes to a RAID 1 unit is slower compared with RAID 0, but about the same as writing to a single disk. This is because the entire data is written to two disks, but in parallel.

Reads
Reads are also very fast in RAID 0. In ideal scenarios, the transfer speed of the array is the transfer speed of all the disks added together, and limited only by the speed of the RAID controller. Reads from RAID 1 may or may not offer such performance boost, depending upon the RAID controller. "Smart" controllers split the reading task in a way that takes advantage of data redundancy and reads different blocks from different disks. This offers a performance boost similar to RAID 0 but for controllers that are not capable of such multiplexing, read speeds and are about the same as a single hard drive.

Думаю может камушек поставить на 3.6Ghz 1С-ка любит тактовую частоту, благо эти ками сейчас 3 рубля пучок стоят, сейчас 2.66.

(6) На чтение одинаково практически, на запись raid0 быстрее, но оно того не стоит. (16) А смысл? У вас что, сервер терминалов?

(17) нет, но на нем делается восстановление последовательности, будет поживей)

Рекомендую Win2008R2+SQL 2008 + памяти минимум 16 гигов + секретный релиз 7.7
SSD по желанию, но рекомендуется. Надо смотреть скорость вашей дисковой системы.
Скуль память любит, а вот SQL2000 плохо ее использует.

Ну и железо хотя бы на 1 поколение поднять, что бы была поддержка новых SATA.

(18) восстановление последовательности на 2000-м хорошо делается с использованием ReconnectNative.
Ну а в более старших релизах эта проблема уже решена.

(0) такая конфигурация очень любит BBU + write back

(21) это и используется, через рекконект

(18) Рекомендую базу перенести на ssd, а на raid1 бэкапиться. На ssd последовательность восстанавливаться веселее будет, чем даже на raid0.

(19) да SQL процесс, съедает все оставшиеся 1.7 гига)

(24) и сколько так SSD протяент ?

(25) AWE включен?

(26) Ну у меня уже 4 года так тянет. Просто SSD надо брать хорошие.

(19) "Скуль память любит, а вот SQL2000 плохо ее использует."
Накормить sql памятью можно, а нужно ли? 99% всей работы ведется с небольшим куском актуальных данных размером один гигабайт. И увеличение памяти не ускорит практически ничего.
(26) У меня в одной конторе год базы БП и ЗУП с довольно плотным потоком ввода данных (по 5000 документов в месяц) на ssd - так износ за год всего 3%.

(27) включен

+(29) Память sql-серверу нужна для запросов по огромным массивам данных (OLAP), при обычной работе в 1с это не актуально.

(28) какие диски используете ?

(0) Очередь к диску есть? Если да - SSD однозначно. У нас серверные от Intel. Ну и переход на новый процессор даст ускорение работы SQL на 150%.

(32) INTEL SSDSC2BB240G4
Посмотрел ресурс - 98%

(0) на нём же и терминалка или все по сети работают ? Загрузка проца какая ?

(35) нет терминального доступа.

(35) На нем терминалка бы точно умерла :)
Да и смысл какой от Sql и терминалки? Только если удаленка.

(31) нужно смотреть по свопингу и попаданию в кэш. я ж не зря написал ТС про тестирование сервера..

(38) В 7.7 без особого использования прямых запросов, да еще и по сети.. тут смотреть не на что. Узкое место - сеть.

(39) да есть на что смотреть. давно-давно (году в 2004) видел, как при изрядно дерьмовой сетке (на хабах) все-таки все упиралось в диски.

(40) На типовых от 1с, где "черные запросы" перетягивают всю таблицу на клиента и потом её фильтруют? Я конечно допускаю сценарии, когда в базу постоянно что-то пишется и при этом идет постоянное хаотичное обращение к данным за разные периоды, но это нетипично.. Или там итоги не закрываются, или еще чего.

(0)  в комплексной главное, выкинуть лишнюю аналитику на 41 счете. и..полетит

(41) ну хз. у меня подход - "сначала диагностика, только потом лечение"

скучный ты

(43) С этим согласен

Вот тут конфиг накидал, стоит ли http://prntscr.com/noa1rq, или для 7.7 на SQL это бесполезно будет ?

(46) Памяти не маловато? Скуль все сожрет, база то 45 гигов....
Ну и HDD для бекапов есть?

(47) сейчас он на 3гигах рабоатет)
Да для бэкапов есть файловый сервер + внешний диск

(48) Сейчас у тебя SQL 2000.
Будет SQL 2008? Он все сожрет :)

(49) я понимаю, у меня просто там всего 4 стоит)

Да будет 2008

(0) странный вопрос, железа на сервере никогда не бывает много...

(52) м.б. но не в случае старого софта, просто нет возможности затестить текущую базу на боле менее новом железе, что бы понять, будет ли прирост в производительности.

(0) Если база ведется давно, то первым делом я бы поудалял в пользовательских каталогах файлы сохраненных настроек .cfg и посмотрел на скорость работы. На файловых базах эти файлики, если размер превышает 300 кБ, реально тормозят работу.

(54) с этим все нормально, в среднем эти файлы по 5-8 килобайт

база SQL порядка 45 гигабайт + 4Gb RAM
4 Гб памяти на сервере ?
оно вообще не должно работать с такими параметрами,
сервер слабее самого дешёвого нового компьютера ?

(56) Это же 7.7. Восьмерочники привыкли к прожорливости 1С :)

(57) у нас на 1С 7.7 все базы вместе весили 100 Гб и объём памяти был 96 Гб (просил 128 Гб)

Объём памяти должен быть больше чем объём всех баз данных !

(58) да офигеть! база 160Г - работала на 16Г на сервере, и в оперативную память точно не упирался...

(58) што???

(60) гугель плЯчетЪ

база 100г, озу 8г, правильно работающий рейд
все отлично работает

(61) ..закупая память камазами

(62) у нас работало 200 пользователей одновременно в 1С 7.7
для мало пользователей может и хватит мало памяти
но не надо экономить, память дешёвая, оно стоило 1000руб/за 1Гиг специальная серверная память 3 года назад, щас ещё дешевле

(64) у нас работало 85+
и в память совершенно не упиралось.

(65) а что собственно сам процесс sqlserver.exe, держит в ОП?

(66) структуру базы, кэш страниц базы, статистики, планы запросов. служебные данные при перебалансировке индексов и т.п.

(67) если логически рассуждать, то чем больше ОП, тем более SQL сможет свалить в ОП, и тем быстрее можно получить наиболее часто используемые данные ?

(67) Да, и тогда упрется все в пропускную способность локальной сети.

(69) в ядро процессора

(64) дешевизна памяти не означает, что ее можно воткнуть сколь угодно много