Вход | Регистрация
 
1С:Предприятие :: 1С:Предприятие 7.7 и ранее

v7: Стоит ли обновлять железо ?

v7: Стоит ли обновлять железо ?
Я
   zenon46
 
10.04.19 - 09:20
Итак, как не смешно бы это звучало, но, есть 7.7 комплексная, база SQL порядка 45 гигабайт, подключений к базе около 45-50, крутится это все на Windows2003 Server + SQL Server 2000, аппаратно самое смешное Core2Duo E8200 + 4Gb RAM + SSD (система) + RAID 0 SAS 2*HHD 300Gb (бэкапы наше все), (0 был выбран для ускорения дисковой подсистемы) на старом контроллере LSI. Вопрос стоит ли обновлять аппаратную часть? Работа становится не комфортной. По мелочи используются прямые запросы.
 
 
   seevkik
 
1 - 10.04.19 - 09:22
Та не, зачем оно нам нужнО? Работает и не трогай
   xXeNoNx
 
2 - 10.04.19 - 09:25
(0) случаем не тут http://zenonline.ru?
   Провинциальный 1сник
 
3 - 10.04.19 - 09:25
У нас примерно то же самое. Нормально работает. Особенно с прямыми запросами.
   Провинциальный 1сник
 
4 - 10.04.19 - 09:26
Вот только raid0 у вас зря - лучше сделайте raid1, ибо в семерке по сети вовсе не скорость записи на диск узкое место
   zenon46
 
5 - 10.04.19 - 09:27
(2) не понял к чему это.
   zenon46
 
6 - 10.04.19 - 09:27
(4) так у 0-вки скорость работы с диском быстрей чем в 1-ке
   xXeNoNx
 
7 - 10.04.19 - 09:28
(5) не в этой конторе еще клюшки починяешь?
   zenon46
 
8 - 10.04.19 - 09:29
(7) не
   zenon46
 
9 - 10.04.19 - 09:29
(7) а там тоже клюшки?
   xXeNoNx
 
10 - 10.04.19 - 09:30
(9) а хз
 
 Рекламное место пустует
   xXeNoNx
 
11 - 10.04.19 - 09:30
+(10) когда-то были точно
   Василий Алибабаевич
 
12 - 10.04.19 - 09:32
(6) С чего бы вдруг быстрее?
   Mikeware
 
13 - 10.04.19 - 09:33
прогнать на sql-сервере "широко известный в узких кругах ограниченных людей" "тест им. vde69".
посмотреть на результаты.
   Василий Алибабаевич
 
14 - 10.04.19 - 09:34
(12) сторно. Спутал с райд-1.
   zenon46
 
15 - 10.04.19 - 09:34
(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.
   zenon46
 
16 - 10.04.19 - 09:40
Думаю может камушек поставить на 3.6Ghz 1С-ка любит тактовую частоту, благо эти ками сейчас 3 рубля пучок стоят, сейчас 2.66.
   Провинциальный 1сник
 
17 - 10.04.19 - 09:42
(6) На чтение одинаково практически, на запись raid0 быстрее, но оно того не стоит. (16) А смысл? У вас что, сервер терминалов?
   zenon46
 
18 - 10.04.19 - 09:44
(17) нет, но на нем делается восстановление последовательности, будет поживей)
   Builder
 
19 - 10.04.19 - 09:46
Рекомендую Win2008R2+SQL 2008 + памяти минимум 16 гигов + секретный релиз 7.7
SSD по желанию, но рекомендуется. Надо смотреть скорость вашей дисковой системы.
Скуль память любит, а вот SQL2000 плохо ее использует.
   Builder
 
20 - 10.04.19 - 09:51
Ну и железо хотя бы на 1 поколение поднять, что бы была поддержка новых SATA.
   Mikeware
 
21 - 10.04.19 - 09:51
(18) восстановление последовательности на 2000-м хорошо делается с использованием ReconnectNative.
Ну а в более старших релизах эта проблема уже решена.
   trad
 
22 - 10.04.19 - 09:52
(0) такая конфигурация очень любит BBU + write back
   zenon46
 
23 - 10.04.19 - 09:54
(21) это и используется, через рекконект
   Провинциальный 1сник
 
24 - 10.04.19 - 09:54
(18) Рекомендую базу перенести на ssd, а на raid1 бэкапиться. На ssd последовательность восстанавливаться веселее будет, чем даже на raid0.
   zenon46
 
25 - 10.04.19 - 09:54
(19) да SQL процесс, съедает все оставшиеся 1.7 гига)
   zenon46
 
26 - 10.04.19 - 09:55
(24) и сколько так SSD протяент ?
   trad
 
27 - 10.04.19 - 09:56
(25) AWE включен?
   Builder
 
28 - 10.04.19 - 09:56
(26) Ну у меня уже 4 года так тянет. Просто SSD надо брать хорошие.
   Провинциальный 1сник
 
29 - 10.04.19 - 09:57
(19) "Скуль память любит, а вот SQL2000 плохо ее использует."
Накормить sql памятью можно, а нужно ли? 99% всей работы ведется с небольшим куском актуальных данных размером один гигабайт. И увеличение памяти не ускорит практически ничего.
(26) У меня в одной конторе год базы БП и ЗУП с довольно плотным потоком ввода данных (по 5000 документов в месяц) на ssd - так износ за год всего 3%.
   zenon46
 
30 - 10.04.19 - 09:59
(27) включен
   Провинциальный 1сник
 
31 - 10.04.19 - 09:59
+(29) Память sql-серверу нужна для запросов по огромным массивам данных (OLAP), при обычной работе в 1с это не актуально.
   zenon46
 
32 - 10.04.19 - 09:59
(28) какие диски используете ?
   ptiz
 
33 - 10.04.19 - 10:02
(0) Очередь к диску есть? Если да - SSD однозначно. У нас серверные от Intel. Ну и переход на новый процессор даст ускорение работы SQL на 150%.
 
 
   Builder
 
34 - 10.04.19 - 10:03
(32) INTEL SSDSC2BB240G4
Посмотрел ресурс - 98%
   Холст
 
35 - 10.04.19 - 10:04
(0) на нём же и терминалка или все по сети работают ? Загрузка проца какая ?
   zenon46
 
36 - 10.04.19 - 10:05
(35) нет терминального доступа.
   Builder
 
37 - 10.04.19 - 10:05
(35) На нем терминалка бы точно умерла :)
Да и смысл какой от Sql и терминалки? Только если удаленка.
   Mikeware
 
38 - 10.04.19 - 10:07
(31) нужно смотреть по свопингу и попаданию в кэш. я ж не зря написал ТС про тестирование сервера..
   Провинциальный 1сник
 
39 - 10.04.19 - 10:18
(38) В 7.7 без особого использования прямых запросов, да еще и по сети.. тут смотреть не на что. Узкое место - сеть.
   Mikeware
 
40 - 10.04.19 - 10:20
(39) да есть на что смотреть. давно-давно (году в 2004) видел, как при изрядно дерьмовой сетке (на хабах) все-таки все упиралось в диски.
   Провинциальный 1сник
 
41 - 10.04.19 - 10:24
(40) На типовых от 1с, где "черные запросы" перетягивают всю таблицу на клиента и потом её фильтруют? Я конечно допускаю сценарии, когда в базу постоянно что-то пишется и при этом идет постоянное хаотичное обращение к данным за разные периоды, но это нетипично.. Или там итоги не закрываются, или еще чего.
   Ёпрст
 
42 - 10.04.19 - 10:28
(0)  в комплексной главное, выкинуть лишнюю аналитику на 41 счете. и..полетит
   Mikeware
 
43 - 10.04.19 - 10:37
(41) ну хз. у меня подход - "сначала диагностика, только потом лечение"
   trad
 
44 - 10.04.19 - 10:43
скучный ты
   Провинциальный 1сник
 
45 - 10.04.19 - 10:43
(43) С этим согласен
   zenon46
 
46 - 14.05.19 - 10:47
Вот тут конфиг накидал, стоит ли http://prntscr.com/noa1rq, или для 7.7 на SQL это бесполезно будет ?
   Builder
 
47 - 14.05.19 - 11:08
(46) Памяти не маловато? Скуль все сожрет, база то 45 гигов....
Ну и HDD для бекапов есть?
   zenon46
 
48 - 14.05.19 - 11:26
(47) сейчас он на 3гигах рабоатет)
Да для бэкапов есть файловый сервер + внешний диск
   Builder
 
49 - 14.05.19 - 11:31
(48) Сейчас у тебя SQL 2000.
Будет SQL 2008? Он все сожрет :)
 
 Рекламное место пустует
   zenon46
 
50 - 14.05.19 - 11:50
(49) я понимаю, у меня просто там всего 4 стоит)
   zenon46
 
51 - 14.05.19 - 11:50
Да будет 2008
   HawkEye
 
52 - 14.05.19 - 11:55
(0) странный вопрос, железа на сервере никогда не бывает много...
   zenon46
 
53 - 14.05.19 - 12:11
(52) м.б. но не в случае старого софта, просто нет возможности затестить текущую базу на боле менее новом железе, что бы понять, будет ли прирост в производительности.
   Pit0n_08
 
54 - 14.05.19 - 12:25
(0) Если база ведется давно, то первым делом я бы поудалял в пользовательских каталогах файлы сохраненных настроек .cfg и посмотрел на скорость работы. На файловых базах эти файлики, если размер превышает 300 кБ, реально тормозят работу.
   zenon46
 
55 - 14.05.19 - 12:39
(54) с этим все нормально, в среднем эти файлы по 5-8 килобайт
   ManyakRus
 
56 - 14.05.19 - 13:10
база SQL порядка 45 гигабайт + 4Gb RAM
4 Гб памяти на сервере ? 
оно вообще не должно работать с такими параметрами,
сервер слабее самого дешёвого нового компьютера ?
   ptiz
 
57 - 14.05.19 - 13:51
(56) Это же 7.7. Восьмерочники привыкли к прожорливости 1С :)
   ManyakRus
 
58 - 14.05.19 - 14:12
(57) у нас на 1С 7.7 все базы вместе весили 100 Гб и объём памяти был 96 Гб (просил 128 Гб)

Объём памяти должен быть больше чем объём всех баз данных !
   Mikeware
 
59 - 14.05.19 - 14:16
(58) да офигеть! база 160Г - работала на 16Г на сервере, и в оперативную память точно не упирался...
   trad
 
60 - 14.05.19 - 14:24
(58) што???
   Mikeware
 
61 - 14.05.19 - 14:25
(60) гугель плЯчетЪ
   trad
 
62 - 14.05.19 - 14:28
база 100г, озу 8г, правильно работающий рейд
все отлично работает
   trad
 
63 - 14.05.19 - 14:28
(61) ..закупая память камазами
   ManyakRus
 
64 - 14.05.19 - 15:21
(62) у нас работало 200 пользователей одновременно в 1С 7.7
для мало пользователей может и хватит мало памяти
но не надо экономить, память дешёвая, оно стоило 1000руб/за 1Гиг специальная серверная память 3 года назад, щас ещё дешевле
   Mikeware
 
65 - 14.05.19 - 15:23
(64) у нас работало 85+
и в память совершенно не упиралось.
   zenon46
 
66 - 14.05.19 - 15:52
(65) а что собственно сам процесс sqlserver.exe, держит в ОП?
   Mikeware
 
67 - 14.05.19 - 15:54
(66) структуру базы, кэш страниц базы, статистики, планы запросов. служебные данные при перебалансировке индексов и т.п.
   zenon46
 
68 - 14.05.19 - 16:07
(67) если логически рассуждать, то чем больше ОП, тем более SQL сможет свалить в ОП, и тем быстрее можно получить наиболее часто используемые данные ?
   zenon46
 
69 - 14.05.19 - 16:11
(67) Да, и тогда упрется все в пропускную способность локальной сети.
   H A D G E H O G s
 
70 - 14.05.19 - 16:21
(69) в ядро процессора
   trad
 
71 - 14.05.19 - 17:06
(64) дешевизна памяти не означает, что ее можно воткнуть сколь угодно много


Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Рекламное место пустует