VO
задержку у кого?
Size: a a a
2020 October 26
Ɐα
на схд
IF
это не решение, оптимизируйте саму БД, выше написал, что необходимо
VO
задержки на схд у кого?
Ɐα
я не очень понимаю, как оптимизация бд приведет к уменьшению блока
EE
я не очень понимаю, как оптимизация бд приведет к уменьшению блока
шта?
Ɐα
шта?
fixed
EE
фух, а я уже 112 начал набирать, доктора тебе вызвать
M
коллеги, подскажите, кто-то сталкивался с ситуацией, когда oracle пишет или читает очень большими блоками(до 2Mb), что приводит к чрезмерной нагрузке на схд?
A
коллеги, подскажите, кто-то сталкивался с ситуацией, когда oracle пишет или читает очень большими блоками(до 2Mb), что приводит к чрезмерной нагрузке на схд?
что значит "читает" - на каком уровне? DB_BLOCK_SIZE то какой?
V
на схд
ну и на клиенте тоже. Естественно при наличии больше одного пути до дисков, то есть меньший блок пойдет параллельно по нескольким путям, что будет в итоге быстрее
VO
2мб блок на 16г сети -- это 1мс. мы точно за 1мс сражаемся? и у нас точно есть уверенность, что если эти 2мб побить на 16 по 128кб, то паралельный запрос в очереди переупорядочится и придет раньше этой пачки?
и точно ли этот паралельный запрос более приоритетен чем запрос от оракла?
и точно ли этот паралельный запрос более приоритетен чем запрос от оракла?
KS
2мб блок на 16г сети -- это 1мс. мы точно за 1мс сражаемся? и у нас точно есть уверенность, что если эти 2мб побить на 16 по 128кб, то паралельный запрос в очереди переупорядочится и придет раньше этой пачки?
и точно ли этот паралельный запрос более приоритетен чем запрос от оракла?
и точно ли этот паралельный запрос более приоритетен чем запрос от оракла?
чтобы запрос пошел впереди остальных у него должен быть HEAD OF QUEUE атрибут
VO
это ответ на какой-то другой вопрос
KS
переупорядочивания запросов по дефолту в SCSI нет
KS
Если оно придет на тот же порт без HEAD OF QUEUE оно будет стоять в очереди
KS
Поэтому разделение на меньшие блоки позволит конечно другому запросу встать раньше в очередь но не в начало очереди
KS
Одним из надежных способов разделения могло бы быть использование нескольких LUN. Поскольку у каждого своя очередь
V
несколько томов не решит проблему толстого блока, ее надо решать либо оптимизированием БД чтобы использовался меньший блок либо больше потоков, тут уж зависит от логики приложения, что ему надо, поток или задержка, либо разбиением блока на уровне ОС (если приложению нужна задержка). Если приложению нужен поток, то тут толстый блок скорее норм и надо увеличивать число потоков в приложении, хотя и разбиение может помочь
VO
Поэтому разделение на меньшие блоки позволит конечно другому запросу встать раньше в очередь но не в начало очереди
да. или нет. в зависимости от времени прихода. но есть и другие вопросы. разные или одинаковые LUN тут не особо влюяют -- или у нас есть мультеплексирование на FC?