2 anonymous (*) (17.10.2003 17:52:13) aka ~finist

>plug-n-play приравнен к dynamic reconfiguration поддержка статических доменов в двух поддерживаемых моделях (Unisys и IBM вроде, если не ошибаюсь) к Sun Dynamic System Domains, паршивенький MS cluster к Sun Cluster-y, нет типа у соляриса lvm-а ну и т.д., Что-то исказили, что-то умолчали, что-то нагло переврали. Вот смотришь, и правда винда-то рулит.

Дык о самом главном не было сказано...

Можно ли по-горячему подключить какие-нибудь жалкие 32 CPU?

> веритас и состик для этого и созданы.
> А 7 разделов на устройсте это ограничение UFS.

Угу... Все-таки никак. Наверное, все-таки ограничение методики разметки диска? Насчет того, что Veritas и Solstice "для этого и сделаны" - клеить лишний уровень над raw-девайсами означает снижать производительность - несмотря на всю "крутизну" этих менеджеров томов. Не находишь?

> sun fire v880 под банковский процессинг

HP ProLiant DL760
IBM xSeries 445

Цена сравнима, характеристики также сравнимы, за исключением процессоров. Впрочем, L2-кэш не играет особой разницы для DB-серверов... А вот по частоте они спарки обломают "по самое не хочу". Иное дело, что вам предложат на тендер то, что вы хотите видеть. Это был раз :-)

Счас будет куда более важное "два": вы будете выбирать то, что у вас уже есть - а я так понимаю, что у вас есть спарки... Соответственно, условия изначально не равные.

Ну и пункт "три" - очень многое определяется софтом, который вы будете гонять. Если он Sun/Sparc-only - естественно, вы x86/x86-64/Itanium выбирать не будете. Isn't it?

2no-dashi (*) (20.10.2003 23:20:43)
"HP ProLiant DL760 "
Ну стоит у нас этот пепелац. Правда двухгодовалой давности. Тебе показать как его плющить начинает на 1000 оракловых соединий? А прогнозируется 2 тысячи. И при таком раскладе компак этот однозначно ляжет. Взять еще таких, но с новыми процами, это значит оттянуть развязывние пупка еще на год - два. Это не решение проблемы.

"Счас будет куда более важное "два": вы будете выбирать то, что у вас уже есть "
см. выше

"Если он Sun/Sparc-only - естественно, вы x86/x86-64/Itanium выбирать не будете"
Нет. будет тот кто даст приемлемое цена/качество. Факт в том что это будет либо чпукс либо соляра. Других вариантов по-моему просто нет.

To no-dashi

Так ты предлагаешь сервера на 32-разрядных процах, которые дешевле 64 разрядных. А ты возьми итаниум и сравни по цене с sunfire v880.

А для DL760 есть 64-разрядный sunfire v440.

"означает снижать производительность - несмотря на всю "крутизну" этих менеджеров томов. Не находишь?" - нет не нахожу. Тебе вообще известно, зачем существуют менеджеры томов? Без VxVM тебе не обойтись, если хочешь построить отказоустойчивую конфигурацию и у тебя несколько дисковых массивов.

"Впрочем, L2-кэш не играет особой разницы для DB-серверов..." Тссс! Об этом не знает техподдержка оракля. Никому не говори, это твое ноухау.

По поводу последних двух вопросов (менджеры томов и L2-кэш) лучше скажи это айтишникам, например, работающим в телекомах. Уверен ты услышишь только матюки.

Нк а про x445 - если бы в России у IBM был trial, этак месяца на 3-4, чтоб попробовать эту вещь, тогда может быть и можно было составить представление о том что может и как. А так, очень много непоняток. Linux на 16 процах - такого еще не видел. Интересно, что они сделали с ядром? IMHO - x445 - это как раз конкретная подсадка на Global Servicec, т.к. и архитектура своя уникальная, да и ядро наверное перелопаченное.

2Krause: показать если можно. Просто у меня работает х360 на ~1800 юзерах и ничего... вопрос больше в том ЧТО делают эти юзера :) Хотя более ответственные\ресурсоемкие задачи естественно на соляре, и меня оттуда не сгонишь! Дело в том, что ратуют за спарки\соляру люди которые более года работали с этой техникой при нормальных нагрузках и видели что твориться с х86 серверами на тех же задачах. А ругают те, кто либо вообще не видел что это такое, либо видел на детских задачках.

> Ну стоит у нас этот пепелац. Правда двухгодовалой давности.

Вспомни, ЧТО и за КАКИЕ деньги выпускала Sun в то время? :-)
Так, для полноты сравнения :-)

> Тебе показать как его плющить начинает на 1000 оракловых соединий?

Не возражаю, хотелось бы взглянуть. Заодно и на IO waits, lock waits, Read/Write cache percentage, распределение таблиц по датафайлам, и ls -la для датафайлов и журналов, статистику по экстентам и размерам таблиц и много чего еще. Поверь, его просто так не плющит :-)

И объем банковского опердня отнюдь не так велик, как ты думаешь :-)

Ничего что вмешаюсь??

>> Ну стоит у нас этот пепелац. Правда двухгодовалой давности.

>Вспомни, ЧТО и за КАКИЕ деньги выпускала Sun в то время? :-) >Так, для полноты сравнения :-)

Он два года назад выпускал тотже v880, по тойже цене что и сейчас.

>Read/Write cache percentage,

Это что за зверь?!

>распределение таблиц по датафайлам, и

Уж а это то как поможет?!

>ls -la для датафайлов и журналов,

И тем более это?!

>статистику по экстентам и размерам таблиц и много чего еще.

А что такое статистика по экстентам?! Ряд красивых, умных слов, но не впопад.

>Поверь, его просто так не плющит :-)

Вот это утвеждение не оспоримо.

>И объем банковского опердня отнюдь не так велик, как ты думаешь :-)

Это уже всем, для избежания всяких мифов: Ежедневный приход в базу опердня банков от 30-го места и ниже не превышает 200МБ, т.е. у нас в стране 97% банков имеют примерно такие объемы.

"Он два года назад выпускал тотже v880, по тойже цене что и сейчас."

Не ты не прав. Сейчас v880 стоит дешевле, чем два года назад, процентов этак на 20-25. Снижение цен,в том числе, было вызвано выходом на рынок V1280, аналогов которого по цене/производительности у HP/IBM просто нет.

Спорить не буду... может и так... но за это время цена упала, частота возрасла с 750 до 1200МГц. Это тольк радует.

И еще: почему все смотрят только на стоимость сервера?! Ведь стоимость системы хранения\софта часто больше...

2no-dashi (*) (21.10.2003 22:35:08)
"Вспомни, ЧТО и за КАКИЕ деньги выпускала Sun в то время? :-) "

Не помню точно. Тем не менее я не могу сказать, что ценовая политика сана как то радикально за два года изменилась. Два года назад я работал в другом месте и мы брали санки как раз в то время.
Можно нарыть цены за 2001 год...

"Не возражаю, хотелось бы взглянуть."
Объективней в конце недели. А самый цирк в конце месяца начинается.
Вот то что имеем щас:
#hw
Report about cpu for ****** on Wed Oct 22 10:11:19 2003

There are 8 CPUs on this system.
The speed of CPU 0 is approximately 695Mhz
The speed of CPU 1 is approximately 727Mhz
The speed of CPU 2 is approximately 700Mhz
The speed of CPU 3 is approximately 699Mhz
The speed of CPU 4 is approximately 700Mhz
The speed of CPU 5 is approximately 699Mhz
The speed of CPU 6 is approximately 700Mhz
The speed of CPU 7 is approximately 699Mhz

Report about memory for **** on Wed Oct 22 10:11:27 2003
Total Memory: 4095.59 Mb
Usable Memory: 4095.58 Mb
General Memory: 1939.77 Mb
Dedicated Memory: 2048 Mb

architecture=IA32
bus_types=PCI2.10,ISA
hw_provider=Compaq ProLiant
machine=Pentium III
num_cpu=8
os_base=UNIX_SVR5
os_provider=SCO
release=5
sysname=UnixWare
version=7.1.1


#rtpm
CPU:
39 %cpu
12 %usr
15 %sys
1 %int
21 %wio
12 %idl

CALLS/s:
7008 calls
1 forks
0 execs
759 reads
492 writs
17071 Krwch


IO/s:
118 reads
2168 rdblk
376 writs
12067 wrblk
2 qlen
28 %busy

MEMORY:
44316 kma
1.09e6 frmem
3.29e6 frswp
48 %mem
9 %swp


PAGING/s:
172 pgins
0 pgots
4265 atchs
78 pflts
1170 vflts

FILESYS/s:
10 igets
50 lkups
98 dirbk
94 %dnlc
12984 inode

LWPS:
836 lwps
0 run
832 sleep
0 zomb
723 procs


TCP/IP:
1107 tcp/s
0 udp/s
0 icmp/s
1108 ip/s
1001 errs

>#rtpm

>CPU: 39 %cpu

Сорри, но это что такое? nice?

>15 %sys 21 %wio

sys+wio многовато... Может что с дисковой не то?

>IO/s:

Хотя тут вроде нагрузка детская... это по всем дискам или по одному устройству?

>CALLS/s: >7008 calls

У меня на 4-ех процовой машинке (спарк) в среднем 10-12тыс, при среднем idle 40-50% >1 forks

Это в секунду то? 8-[ ]

>MEMORY: 1.09e6 frmem

Целый гиг простаивает! Может его лучше под db cache отдать?

Cache read/write - это процент попадания в кэш при чтении и попадания в кэш при записи.

По поводу экстентов - имелись ввиду параметры, с которыми создавались "тяжелые" таблицы.

Первичный диагноз - датафайлы созданы на файловой системе (судя по 15 %sys) и слегка незаточен кэш и ввод-вывод вообще. Рецепт: сходить на OTN и прочесть цитату: "If the %wio column value is consistently greater than 20, the system is I/O bound" - а у тебя, как я посмотрю, он по твоему заверению "в покое" на предельной грани?

Попробуй поднять число IO slaves, поднять DB_CACHE_SIZE и число буферов. Вынеси REDO logs из файловой системы (если они на ней).

И покажи все-таки ls -Lla для датафайлов :-)

>Cache read/write - это процент попадания в кэш при чтении и попадания в кэш при записи.

Ну при чтении понятно, а вот про запись: redo log buffer знаю, но "процент попадания" в него это что? Dirty buffers - тоже знаю... но тоже как-то не из той оперы...

>поднять DB_CACHE_SIZE и число буферов.

Это UnixWare, на ней не работает 9-ка, в 8-ке этот параметр называется DB_BLOCK_BUFFERS.

Но уже вроде Krause забил на это дело. А так я с тобой no-dashi согласен надо смотреть в сторону ИО, т.к. процы тут особо не причем.

Факин юниксварь :-)

процент попадания в кэш = logical ops - physical ops / logical ops

По документации :-)

А у Krause, похоже, типичный пример почти-дефолтных установок. Вдобавок ко всему, в UnixWare на моей памяти не работало много чего во вводе выводе, из-за чего приходилось идти на ухищрения типа "подбора количества процессов IO" :-)

2no-dashi:

>процент попадания в кэш = logical ops - physical ops / logical ops

Нет ты мне скажи что такое попадания в кэш при записи? И где в документации это написано?

Попадание в кэш при записи - это когда повторное изменение "догоняет" страницу, лежащую в списке измененных, до того как она будет сброшена на диск. Применяется в случае расположения данных на файловой системе, см также описание разборок с %rcache и %wcache, A66130 3-19

Номер такой доки не нашел, но все-равно понял о чем ты...

А Krause ушел... Либо спарки покупать, либо Oracle настраивать :-)

Железку пожирнее купить это конечно тоже решение, но не по нашенски это как-то...

-

Ну-у-у-у... С таким подходом оно на чем угодно тормозить будет :-)

2anonymous (*) (22.10.2003 11:24:24)
"Сорри, но это что такое? nice? "
Да
"Целый гиг простаивает! Может его лучше под db cache отдать?"
Дык этож бубль гум (с) То есть скотина... Ниче ты в 8рку под ней больше того что есть не отдашь...

2no-dashi (*) (22.10.2003 22:39:35)

"Вынеси REDO logs из файловой системы (если они на ней)."
Вынесено.

"the %wio column value is consistently greater than 20, the system is I/O bound"
Я на мало-мало нагруженной скотине ни разу не видел less than 20:)

"И покажи все-таки ls -Lla для датафайлов :-)"
Нафиг?
"Факин юниксварь :-) "
Это точно..

"он по твоему заверению "в покое" на предельной грани"
:)
Вот для сравнения что происходит по пятницам:) И это еще ничего:)


CPU:
51 %cpu
44 %usr
5 %sys
1 %int
47 %wio
2 %idl

CALLS/s:
12703 calls
0 forks
0 execs
4268 reads
1484 writs
31552 Krwch

IO/s:
1329 reads
20912 rdblk
868 writs
14188 wrblk
1 qlen
21 %busy

%cpu - the percentage of user, system time and time spent processing interrupts

так что это не nice.

>Я на мало-мало нагруженной скотине ни разу не видел less than 20:)

не уверен на счет скотины, но может просто мало-мальски сбалансированных систем не было?

Какая у тебя подсистема IO? Как она поделена? Чтобы выдать 1329 IOs при запись\чтение как 40\60, надо минимум RAID10 из 6 дисков, а вообще стоит придерживаться правила не более 50IOs на один физический современный винчестер в среднем за 5 минут, т.е. в твоем случае должно быть более 20 дисков. Соответственно на 20 дисков минимум два 2-х канальных контроллера. У тебя слишком много записи, проверь не идут ли сортировки на диске (это уже в оракле смотреть). Маловероятно что у тебя с такой скоростью в данные заливают.

Проблема однозначно в IO, а не в процах. Топик у нас такой если кто забыл :)

Если что пиши на astatech(bla)mail.ru решим!

"два 2-х канальных контроллера"
Так оно и есть.
т.е. в твоем случае должно быть более 20 дисков
24
"проверь не идут ли сортировки на диске "
Что ты имеешь ввиду под "сортировки" ?
"Проблема однозначно в IO, а не в процах"
Оч может быть.

Ну, что-то подобное я ожидал :-)

По первому снапшоту было видно, что у тебя идет много апдейтов/инсертов - причем оракл виснет внутри юниксвари (на записи). Ты скажи, у тебя датафайлы на файловой системе или все-таки "сырые"?

Ввод-вывод подскакивает почти в два раза, %wio во столько же. Если бы "хромало" железо (не хватало полосы для передачи данных) - картина была бы иной - %wio подскочил бы гораздо выше, чем в два раза.

Попробуй, во-первых, расположить оракла на семи процессорах из восьми (возможно, система будет быстрей отрабатывать IO), и скорректировать число io-шников (в сторону увеличения). И попробуй все-таки увеличить объем выделяемой ораклу памяти (система явно заявляет, что может раздать два гига, а не один).

Под сортировками понимаю операции во временном сегменте. На количество сортировок на диске, помимо самих запросов, влияет sort_area_size. Тем более явно ты ее можешь увеличить, у тебя целый гиг памяти свободной. Т.е. для твоих 1000 соединений, как раз по 1МБ можно выделить смело.

Проверь статистику ввода\вывода на temp tablespace и на носители где расположены файлы этого tablespace.

Как эти 24 винчестера "нарезаны"? Это один RAID 10 массив или ...? Нужна инфа о расположении датафайлов по носителям, и о том что представляют из себя сами носители.