LINUX.ORG.RU
ФорумAdmin

RAID


0

2

Всем добрый день, Вопрос в следующем, у меня есть SAS RAID-контроллера Adaptec RAID ASR-5805, я поставил debian х64 и postgesql х64, собрал raid10 при работе с базой объемом в 50 Гб, у меня медленно работала база, из-за RAID-контроллера, я удалил raid10 и поставил mdadm, после чего собрал 10 RAID, база начала работать быстрее. Вопрос: есть ли способ ускорить работы базы закупкой нового RAID контроллера или установкой другого софтварного? если нужно закупить другой RAID контроллер, то если есть примеры покажите какой.

Сомнительно что дело в рейде было, судя по прошлым темам вашим.

ventilator ★★★ ()

в линуксе софтовый рейд делается средствами ядра, и установить другой не получиться, если не считать lvm страйпов. Однако их использовать смысла мало.

ventilator ★★★ ()
Ответ на: комментарий от ventilator

Вот конфиг:

shared_buffers = 6GB                    # min 128kB or max_connections*16kB
                                        # (change requires restart)
temp_buffers = 32MB                     # min 800kB
#max_prepared_transactions = 5          # can be 0 or more
                                        # (change requires restart)
# Note:  Increasing max_prepared_transactions costs ~600 bytes of shared memory
# per transaction slot, plus lock space (see max_locks_per_transaction).
work_mem = 256MB                                # min 64kB
maintenance_work_mem = 256MB            # min 1MB
#max_stack_depth = 2MB                  # min 100kB

# - Free Space Map -

max_fsm_pages = 204800                  # min max_fsm_relations*16, 6 bytes each
                                        # (change requires restart)
max_fsm_relations = 8000                # min 100, ~70 bytes each
                                        # (change requires restart)

# - Kernel Resource Usage -

max_files_per_process = 1000 
fsync = on                              # turns forced synchronization on or off
synchronous_commit = off
enable_seqscan = off
default_statistics_target = 100 
autovacuum = on                         # Enable autovacuum subprocess?  'on'
                                        # requires track_counts to also be on.
#log_autovacuum_min_duration = -1       # -1 disables, 0 logs all actions and
                                        # their durations, > 0 logs only
                                        # actions running at least that time.
#autovacuum_max_workers = 3             # max number of autovacuum subprocesses
autovacuum_naptime = 30min 
default_with_oids = on
escape_string_warning = off
effective_cache_size = 8512MB
Вроде все гуд настроил, если что не так скажите

vlershov ()
Ответ на: комментарий от ventilator

советую ещё купить ups :) А вот на счёт софтового рейда... Как минимум стоит попробывать оба варианта и выбрать самый быстрый.

true_admin ★★★★★ ()
Ответ на: комментарий от ventilator

effective_cache_size = 8512MB - ересь, писал еще в прошлой теме вам. Поставьте 128MB, и включите логирование медленных запросов

По рекомендации фирмы 1С effective_cache_size - должен быть чуть больше половины памяти, как включить логирование медленных запросов? Что ускорится если я поставлю effective_cache_size = 128?

vlershov ()
Ответ на: комментарий от vlershov

Меня интересует так же вопрос, почему на mssql servere документы быстрее проводятся нежели в postgresql. Если б убрать этот момент все было б чудесно.

vlershov ()
Ответ на: комментарий от vlershov

Если бы вы прочитали документацию постгреса то поняли бы что effective_cache_size говорит планировщику сколько даннх лежит в кеше для каждого запроса и планировщик думая что у вас 8 гигов в кеше спокойненько делает фулл скан, потому что для RAM это дешево. А по факту данные у вас на диске лежат, и надежды планировщика не оправдываются. Вы уверены что у вас закешировано 8 гигов данных под любой запрос? По поводу медленных запросов - ищется в гугле за три минуты.

ventilator ★★★ ()
Ответ на: комментарий от vlershov

Вопрос про mssql вы можете спросить у 1с, почему оно у них так написано - это не проблема постгреса

ventilator ★★★ ()

Нечисто.

Аппаратный массив оказался медленнее программного? Что-то здесь нечисто.

Camel ★★★★★ ()
Ответ на: комментарий от annoynimous

А как он может быть fake-raid, если я захожу в менеджер адаптера и там его собираю, просто указываю, что вот эти 4-ре жестких диска запихнуть в 10 raid и все.

vlershov ()
Ответ на: Нечисто. от Camel

> Аппаратный массив оказался медленнее программного? Что-то здесь нечисто.

Вы так говорите, как будто это что-то необычное.

AnDoR ★★★★★ ()
Ответ на: комментарий от AnDoR

Что-то необычное.

Аппаратный массив оказался медленнее программного? Что-то здесь нечисто.

Вы так говорите, как будто это что-то необычное.

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

Camel ★★★★★ ()
Ответ на: комментарий от annoynimous

Аппаратный.

А есть данные, что это настоящий аппаратный, а не fake-raid?

8 SAS портов, большая микросхема с радиатором. Лень лезть в спецификации, но по виду вполне серьёзный контроллер.

Camel ★★★★★ ()
Ответ на: комментарий от vlershov

Практика без теории слепа.

У меня есть два примера когда аппаратные оказались медленнее программный, я в это м ни чего такого не вижу.

Это хорошо, что есть примеры, но есть ли у вас объяснение почему так происходит? Имея объяснение, возможно, нам (мне) удалось бы избежать такой ситуации в будущем. Дело ли в контроллере (производителе или конкретной модели), драйвере, способе подключения?

Camel ★★★★★ ()
Ответ на: комментарий от vlershov

Само железо.

При программном raid отрабатывает процессор, чем сильнее проц тем лучше, а при апаратном отрабатывает драйвер и само железо.

Согласен, что нагрузка на ЦП невелика. Но ведь и микросхема на контроллере стоит не абы какая, по идее она с XOR'ом должна справляться быстро и решительно. Я сам большой любитель программных массивов, но ведь должно же быть у аппаратных какое-то преимущество.

Camel ★★★★★ ()
Ответ на: Аппаратный. от Camel

Скорее всего, они купили его без батарейки, а поэтому шиш им, а не кэширование. А без кэша все ужасно печально

annoynimous ★★★★★ ()
Ответ на: комментарий от vlershov

Да легко =) У Вашего рейд-контроллера есть энергонезависимая память и батарейка?

oxumorron ()
Ответ на: Нечисто. от Camel

давайте мы не будем обсуждать какие то домыслы, не подтвержденные фактами. Медленнее аппаратный рейд или быстрее софтового у ТС неизвестно, потому что тестов не проводилось или результаты их не показаны. Подозреваю что аппаратный рейд был на x86 системе(судя по прошлой теме),а после установки x86_64 работать стало быстрее, потому что shared_buffers = 6GB хотя могу и ошибаться. Сколько wa в среднем по vmstat 1? Для тестов скорости рейда можете заюзать fio.

ventilator ★★★ ()
Ответ на: комментарий от ventilator

Тестил и на х86 и на х64, софтовый быстрее, замерял бонально по секундомеру проведением документа. Сегодня буду общаться с разработчиками raid адаптера мож чего скажут хорошего

vlershov ()

У RAID куча настроек, ищи оптимальные под задачу методом тестов.

macumazan ★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.