Форум по программам и оборудованию > >

Скорость работы с диском на сервере супермага

24.05.2018 1:48


[ОТВЕТИТЬ]
18.04.2013 15:29
whitewizard
 
Собрался новый сервант покупать под ЦО и озадачился дисковой системой.
У кого какая скорость? на чём организовано? SAS, SATA, SSD, SAS+SSD-кэшинг?
какой RAID?
большая разница на одном железе на винде и не-винде?
18.04.2013 16:46
Troll
 
RAID однозначно 10
Если на что-то вроде HP EVA денег не хватает, то смотрел бы все же в сторону того, чтобы для оперативной работы поставить SAS минимум из 12 винтов в 10ке, а для аналитики - SSD, штуки 4, тоже в 10ке.
Разница между Linux и виндой - процентов 10-15 в пользу первого, и в первом нет геморроя с тем, чтобы какая-то гадость вроде кидо приехала.
18.04.2013 16:48
whitewizard
 
нужна не теория, а гольная практика
18.04.2013 17:00
Troll
 
Голее не бывает. Все это, включая EVA, перед глазами. Точные модели железок не полезу смотреть без особой на то причины, но какие-то тесты могу привести. SAS, описанный выше, пишет сам на себя до 175Мб/сек в один поток, SSD - около 200Мб/сек, но если база нагруженная, то ставить SSD на оперативку страшно. А аналитику раз за ночь влить, думаю, пойдет.
18.04.2013 17:02
Kryukov
 
Цитата:
whitewizard нужна не теория, а гольная практика
Предложи для единообразия чем затестить и выложим...
у меня SAS2 рой 10 5 дисков(один на подхвате) по 450, контролеры как Adaptec такт и LSI
18.04.2013 17:12
whitewizard
 
да хотя бы еверестом
линейное чтение
у меня 150 и не хватает
18.04.2013 17:25
Troll
 
вот евересты всякие забудьте. копирование в тоталкомандере и то, как работает с файлами БД - совершенно разные вещи.
150 для чего не хватает? alter table smspec move сколько выполняется? аналитика отдельно от оперативки лежит? синтетику оставьте десктопным писькомерам, для серверов это все не годится. В качестве примера можете вышеуказанный move использовать или
Код:
set timing on
exec dbms_stats.gather_table_stats('SUPERMAG','FFMAPREP',degree=>16,cascade=>true);
18.04.2013 17:46
baggio
 
Цитата:
Troll
Код:
set timing on
exec dbms_stats.gather_table_stats('SUPERMAG','FFMAPREP',degree=>16,cascade=>true);
Присоединен к:
Oracle9i Enterprise Edition Release 9.2.0.8.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.8.0 - Production

SQL> set timing on
SQL> exec dbms_stats.gather_table_stats('SUPERMAG','FFMAPREP',degree=>16,cascade=>true);

Процедура PL/SQL успешно завершена.

Затрач.время: 00:01:08.02
SQL>
18.04.2013 17:51
Troll
 
ну хотя бы еще
Код:
select sum(bytes)/1024/1024/1024 from dba_segments where segment_name='FFMAPREP';
указали...
18.04.2013 17:58
baggio
 
select sum(bytes)/1024/1024/1024 from dba_segments where segment_name='FFMAPREP';


SQL> select sum(bytes)/1024/1024/1024 from dba_segments where segment_name='FFMAPREP';

SUM(BYTES)/1024/1024/1024
-------------------------
,4140625
18.04.2013 17:59
whitewizard
 
SQL> set timing on
SQL> exec dbms_stats.gather_table_stats('SUPERMAG','FFMAPREP',degree=>16,cascade=>true);

Процедура PL/SQL успешно завершена.

Затрач.время: 00:00:42.65
SQL> select sum(bytes)/1024/1024/1024 from dba_segments where segment_name='FFMAPREP';

SUM(BYTES)/1024/1024/1024
-------------------------
,024902344

Затрач.время: 00:00:00.27
18.04.2013 18:03
Troll
 
Цитата:
whitewizard ,024902344
тогда не понимаю, что для чего не хватает :( Или аналитика очищена?
18.04.2013 18:08
Troll
 
exec dbms_stats.gather_table_stats('SUPERMAG','FFMAPREP',degree=>16,cascade=>true);SQL>

PL/SQL procedure successfully completed.

Elapsed: 00:15:15.29

Около 10Гб.
18.04.2013 18:13
whitewizard
 
Цитата:
Troll тогда не понимаю, что для чего не хватает :( Или аналитика очищена?
всё в рабочем режиме. не хватает скорости обмена с вениками.
мне не нравится.
19.04.2013 09:53
Troll
 
Цитата:
whitewizard всё в рабочем режиме. не хватает скорости обмена с вениками.
мне не нравится.
Это субъективно. И не отвечать на вопросы - признак дурных манер.
Почему именно диски виноватыми назначены? Какие именно операции долгие? Разнесена ли аналитика с оперативными таблицами?
19.04.2013 10:09
whitewizard
 
всё разнесено. и индексы на отдельном зеркале и аналитика.
загрузка процессора небольшая и всё упирается в винты.
19.04.2013 10:14
Troll
 
Это может быть и следствием неправильных планов запросов. Кроме того, "небольшая" это не одно ядро в потолке? "Упирается", это значит, что в момент проблем они выдают 150Мб/сек? Сколько памяти? Тема достаточно обширная, чтобы решать эту проблему исключительно увеличением пропускной способности винтов.
19.04.2013 10:18
whitewizard
 
на серванте два ксеона, 16 гигов памяти (доступно 5)
средняя общая нагрузка на процы 15%
19.04.2013 10:23
Troll
 
Это не то... "Общая нагрузка на процы" в данном случае, как и общая температура по больнице, ничего не дает. Большинство операций не параллелятся и тут решает быстродействие одного ядра. Смущает "доступно 5".
19.04.2013 12:33
whitewizard
 
ага. не стал больше памяти ораклу отдавать.
20.04.2013 07:49
OlegON
 
почему? помойка?
20.04.2013 09:20
whitewizard
 
да показалось, что 8 гигов ему достаточно
20.04.2013 10:04
OlegON
 
а остальную память-то куда дел? и зачем?
20.04.2013 10:53
whitewizard
 
8.6 съел оракл, 5.2 свободно
2 гектара ушло по мелочи на 2008 сервер
20.04.2013 11:03
OlegON
 
Я бы дал 12 ораклу, ему сколько ни дай... Зачем пустовать-то? Кеширование у него свое...
20.04.2013 11:21
whitewizard
 
как говорится, shit question
но изначально вопрос другой был
20.04.2013 23:28
OlegON
 
Вопрос был в том, что "хочу, чтобы диски быстро работали". Но проблема, что хочешь ты, чтобы база быстро работала, а не диски. А это действительно, не только в дисках заключается.
25.08.2013 13:01
whitewizard
 
Приехал таки новый сервер с 8 SAS винтами по 300Гб. Скорость работы с памятью в три раза больше, чем раньше.

Решил потестить на разных массивах. Автоматом рэйд контролер разбил на RAID6. Скорость весьма приличная, как мне показалось.

Завтра буду проверять на зеркале (RAID1).
25.08.2013 14:57
whitewizard
 
а это другой сервер, купленный лет пять назад

25.08.2013 23:50
Troll
 
к сожалению, быстрый обмен в синтетическом тесте, даже более того, большая скорость копирования файлов бд и работа самой БД - две большие разницы... мне очень нравятся ssd именно за счет отсутствия задержек в рандомном чтении...


Опции темы


Часовой пояс GMT +3, время: 01:48.

 

Форум сделан на основе vBulletin®
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd. Перевод: zCarot и OlegON
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.