[ТЕМА ЗАКРЫТА]
Опции темы
30.03.2010 08:05  
kadr
Если есть возможность, то надо увеличивать количество дисков в системе, Oracle любит когда много дисков
 
30.03.2010 08:09  
Vovantus
Цитата:
Сообщение от kadr
Если есть возможность, то надо увеличивать количество дисков в системе, Oracle любит когда много дисков
не совсем понятно. любит, когда табличные пространства разнесены на разные физические диски, или любит, вообще, пропускную способность дисковой подсистемы?
 
30.03.2010 09:39  
OlegON
Не буду перечитывать написанное, может повторюсь, Супермагу в настоящий момент нужна частота проца. Т.е. у меня, например, в нее достаточно часто упоры. Т.е. винты отдают быстро, а проц считать не успевает. Сумбурно, но попробую резюмировать. Количество процессоров влияет на количество поддерживаемых пользователей (10 одновременно работающих пользователей ~ 4 ядра для "влет"). Частота проца (условно говоря) - на скорость выполнения операций. Мизерная часть запросов супермага параллелится.
Что касается винтов, то redo, например, всегда пишется последовательно, т.е. рейд им как-то... Зато возможность разнести redo с users - очень большой бонус. И в целом, возможность оперировать большим количеством физических точек монтирования - большой бонус для проведения оптимизации. Я обычно жертвую индексами и аналитикой, выкладывая их на ненадежные носители за счет выделения освободившихся носителей в отдельные диски.
Тебе, Vovantus, рекомендую все таки прогнать оптимизатора, он покажет основные ожидания. Оттуда и будешь смотреть, чего тебе больше не хватает.
 
30.03.2010 10:12  
Vovantus
Цитата:
Сообщение от OlegON
Что касается винтов, то redo, например, всегда пишется последовательно, т.е. рейд им как-то...
фишка рэйда в том, что в случае стрейпа, запись данных производится одновременно на два (и более) физических диска. условно, первый блок - на один винт, второй блок - на второй винт. так что даже в случае с redo, запись, теоритически, должна быть выше.

З.Ы. продолжая свою мысль, скажу, что при использовании рйдов 0 и 1 оракл думает, что у него один физический диск. и эффект этот создаётся на самом низком уровне.
 
30.03.2010 10:38  
OlegON
это страйп (stripe), только у меня насчет скорости было другое мнение, поправьте, если не так:
пишем блок, ждем подтверждения его записи, пишем второй, ждем подтверждения записи и т.п., т.е. в случае одного записывающего потока, преимуществ у страйпа не будет. Про продолжение мысль, что думает не Oracle, а ОС. Пишет и читает все равно операционка, даже в случае с raw-устройствами.
 
30.03.2010 10:55  
Vovantus
Цитата:
Сообщение от OlegON
пишем блок, ждем подтверждения его записи, пишем второй, ждем подтверждения записи и т.п., т.е. в случае одного записывающего потока, преимуществ у страйпа не будет.
если рассуждать теоритически и с точки зрения ОС, всё верно говоришь. но на практике, почему-то, даже на обычных десктопных машинах, при использовании страйпа наблюдается некое увеличение производительности дисковой подсистемы. и чем выше нагрузка на дисковую подсистему, тем больше это приимущество. играя в игры, сложно создать такую нагрузку на дисковую подсистему, чтобы она получила реальный прирост от страйпа. а вот в случае большого количества запросов, характерного для БД, думаю, приимущество будет. ведь суть-то как раз в том, что райд организовывается на самом низком уровне, т.е. даже ниже чем операционка. для сравнения. есть такое понятие как очерёдность команд на САТАвском интерфейсе. так вот там как раз запросы на чтение/запись сначало поступают в буфер, затем сортируются и только потом идёт реальная запись/чтение данных с диска, по уже ранее оптимизированному сценарию. похожая ситуация и с райдом. т.е. поступающие запросы на запись/чтение один фиг быстрее реального чтения/записи и таким образом создаётся буферная область этих запросов, которые потом тупо деляться и посылаются на определённый физический носитель. в общем, это всё походу мысли написал, без привязки к тестам. если что, поправьте..
 
30.03.2010 11:08  
OlegON
Ты как-то резко перескочил с redo на всю БД в целом... И те же игры могут отсвопиться, что уже даст как минимум два потока чтения/записи. А нормальные игры пишут/читают в несколько потоков и неизвестно что еще там параллельно работает.
 
30.03.2010 11:16  
Vovantus
Цитата:
Сообщение от OlegON
Ты как-то резко перескочил с redo на всю БД в целом...
думаю, реально не получиться сделать так, что бы обрабатывалось только одно ТП. помимо него, происходит ещё масса обращений на чтение/запись и касаются они не только БД. но вообще вопрос, конечно, интересный. я если честно, был уверен, что приимущество от страйпа/зеркала будет заметно даже в случае однопоточного обращения к диску. как бы это на практике проверить?
 
30.03.2010 12:19  
OlegON
Так о том и речь, что если на диске кроме чего-то одного не лежит, то и читать/писать больше нечего. В этом плане удобно оттаскивать аналитику на другой диск... Пусть хоть 100 отчетов одновременно запустят - лягут отчеты, а не оперативная работа.
 
30.03.2010 14:05  
Vovantus
Цитата:
Сообщение от OlegON
Так о том и речь, что если на диске кроме чего-то одного не лежит, то и читать/писать больше нечего. В этом плане удобно оттаскивать аналитику на другой диск... Пусть хоть 100 отчетов одновременно запустят - лягут отчеты, а не оперативная работа.
для выявления истины, предлагаю провести эксперимент у меня есть два свободных сказёвых винта. есть рабочий сервак в послерабочее время. размер винтов небольшой, но для эксперимента хватит. протестируем их в режиме чтения/записи для рэйда 0 и 1, а также, без рейда. ну что, есть желание провести эксперимент? с тебя требуется придумать запрос, который будет серьёзно нагружать redo при чтении и записи, а также показывать результат тестирования. ну и перенос redo нужно будет сделать, сам не смогу.
 
 


Опции темы



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

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