Средно натоварване – клъстерна версия

 Общи  Коментарите са изключени за Средно натоварване – клъстерна версия
Февр. 172014
 

Наскоро постнах една заявка, която може да даде средното натоварване на базата по дни, седмици и месеци. Работи чудесно… докато не го пуснах върху RAC база.

При RAC има по един ред за всеки node и моята стратегия да вадя резултатите от предния ред водят до покъртителни резултати. Така че – ето новата, RAC-aware версия:

select trunc(this_day, 'MONTH'), avg(day_db_time), sum(cnt) scnt
  from (select this_day, count(1) cnt,
                sum(case
                       when snap_db_time > 0 then
                        snap_db_time/1000/1000/60/60/24
                       else
                        null
                     end) day_db_time
           from (select trunc(begin_interval_time) this_day, tm.snap_id,
                         value - lag(value, 1) over(order by tm.instance_number, tm.snap_id) snap_db_time
                    from dba_hist_sys_time_model tm, dba_hist_snapshot s
                   where tm.stat_name = 'DB CPU'
                     and s.snap_id = tm.snap_id
                     and s.instance_number = tm.instance_number
                     and s.begin_interval_time > add_months(trunc(sysdate, 'YEAR'), -24)
                     and s.begin_interval_time < trunc(sysdate, 'MONTH')
                     )
          group by this_day)
 group by trunc(this_day, 'MONTH')
 order by 1

Единствената разлика е, че внимавам кой instance е на предния ред, да не вадя някакви глупости. Работи чудесно и за single instance бази.

 Posted by at 19:33
Февр. 102014
 

Шест години са ужасно дълго време за живот на домашен компютър. През февруари 2008 се бях наточил да сглобя безшумен компютър, и почти успях. Преди 3 години смених видеото, за да мога да гледам спокойно FullHD филми на телевизора. Но компютърната техника, макар и да е позабавила темпото, не търпи помотване. И доде време за по-сериозен ъпгрейд.

Кутия
Тук нямам оплаквания. Използвам добрата стара Colermaster Centurion 534 +Plus. Просторна, стабилна. Дебели ламарини, чудесен въздушен поток. Захранването е един стар, но железен Fortron Zen 400W – никакви вентилатори.

Дъно
За основа на системата сложих дъно G1.Sniper A88X. Добро дънце, което има всичко необходимо и обещава да бъде достоен наследник на стария Asus. Тук няма какво толкова да шуми, освен ако случайно не попаднете ня някое малко дразнещо вентилаторче. Но май такива дъна не съм виждал напоследък.

Процесор
Поцесра го избирах по консумацията. Спрях се на AMD A10-6700 X4. Избора направих така: започнах от бюджет 300 лв, и цъках надолу докато намеря процесор с ниска консумация. Този конкретно гори 65W, което е много важно за пасивното охлаждане.

Дискове
В края на миналата година успях да се сдобия с един 480 GB Crucial M500 на скандална цена в английския Amazon. Имаше някакви след-коледни намаления и го взех за по-малко от 400 лв. Което за свестен SSD, при това с такъв чудовщен размер, си е страшна сделка. Освен него имам и 120 GB Intel 520, който преди 2 години ми излезе доста по-скъпо. Така успях да разкарам и последния хард диск от кутнията. Да не говорим, че Windows 8.1 зарежда за 4 секунди (!) – от boot менюто до готовност за работа.

Ако ми потрябва дисково пространство, имам два 2.5″ USB 3.0 външни диска, които хем са досататъчно бързи за да търкалят виртуалки, хем са и достатъчно тихи (особено като са изключени): Samsung M3 и Platinum MyDrive (пак самсунг). Всъщност SATA3 и USB 3.0 бяха нещата, които ме накараха да сменя дъното.

Видео
Всъщност няма такова. Използвам вграденото в пороцесора. Но то е достатъчно за гледане на HD филми – аз не съм геймър.

Охлаждане
И на края остана най-голямото предизвикателстно – охлаждането на процесора. Има много съвременни охлаждания, фокусирани върху извеждането ма максимално количество топлина от този най-горещ компонент в кутията. За съжаление те са фокусирани към overclock-ерите, а не към бедните ДиБиЕи, които просто искат да си пуснат две виртуалки с RAC бе да пречат на децата да спят. След доста ровене успях да открия само три смислени предложения:
Огромното и горзно алуминиево туловище SilverStone HE02

HE02

Черния куфар Zalman FX100

fx100

Относително красивия меден NOFAN CR-95C

nofan

За съжаление, нито едно от тези чудовища не може да се мери с елегантната красота на старият ми Apack ZEROtherm BTF95

bf

Така че след доста ревюта и размисли избрах HE02. И въпреки че бях донякъде подготвен, останах втрещен когато пристигна и го взех в ръцете си. Това нещо е огромен кютук. Кутията ми, която не е от най-малките, едва го побра.

Инсталацията не беше много лесна. Опътването е постничко, а изработката на закрепващите елементи е… хм, малко китайска. Наложи се намесата на пила, чук, клещи, и, разбира се, тел (a.k.a. българско инженерно влакно). А, и много пъти „майката“, докато успея да го закрепя. Отне ми 2-3 часа. Но вече всичко е на място и процесора държи 30-36 градуса 🙂

Единствената движеща се част, която остана по машината, е супер тихия вентилатор Arctic Cooling Arctic Fan 12L, който ползвам вече шеста година без никакви проблеми. Закрепен е на задната част на кутията и отвежда въздуха от радиатора на процесора.

И така, 6 години по-късно, мога да кажа, че мисията е изпълнена!

 Posted by at 8:26

Средно натоварване

 Общи  Коментарите са изключени за Средно натоварване
Февр. 052014
 

Рано или късно годината приключва. Трябва да се правят отчети, бюджети, трябва да кажем „нашите бази се държаха така и така през годината“. От къде да вземем тези данни?
Както съм казвал и преди, при нас пазим AWR репорти за доста време назад. Едно време смятах от тях как расте базата, за да си планираме storage; сега смятам и как расте натоварването.

select trunc(this_day, 'MONTH'), avg(day_db_time), sum(cnt) scnt
  from (select this_day, count(1) cnt,
                sum(case
                       when snap_db_time > 0 then
                        snap_db_time/1000/1000/60/60/24
                       else
                        null
                     end) day_db_time
           from (select trunc(begin_interval_time) this_day, tm.snap_id,
                         value - lag(value, 1) over(order by tm.snap_id) snap_db_time
                    from dba_hist_sys_time_model tm, dba_hist_snapshot s
                   where tm.stat_name = 'DB time'
                     and s.snap_id = tm.snap_id
                     and s.begin_interval_time > add_months(trunc(sysdate, 'YEAR'), -24)
                     and s.begin_interval_time < trunc(sysdate, 'MONTH')
                     )
          group by this_day)
 group by trunc(this_day, 'MONTH')
 order by 1

Това query е доста коварно. В крайна сметка дава средното натоварване (DB time) по месеци за последните 2 години, ако имате толкова awr данни. Който пази само месец, може да си го направи по дни.

Един от тънките моменти е, че DB time (както всяка системна статистика) е постоянно нарастваща величина, която се отчита от стартирането на instance. Заявката взема стойността от всеки snapshot и от нея вади стойността предишния. Ако случайно имате restart на instance, се получава отрицателно число - защото брояча започва от нула. За нуждата на грубата статистика такива данни просто ги пропускам, понеже ни се случват адски рядко и не могат да повлияят значително.

SQL> select sysdate, startup_time, trunc(sysdate-startup_time) Days_since_restart from v$instance;

SYSDATE   STARTUP_T DAYS_SINCE_RESTART
--------- --------- ------------------
05-FEB-14 19-FEB-13                350

Сумирам данните по дни, после взимам средната стойност за месеца.

Честно казано трябваше ми известно време за да осмисля и подкарам правилно заявката. Ако някой забележи грешка в нея, моля пишете в коментарите.

Събраните дании чертая в excel - една колонка за DB time, една за DB CPU (where tm.stat_name = 'DB CPU') и за сравнение - броя бизнес транзакции през месеца (за да покажа каква работа сме свършили реално). Много приятно е като изпратя на Големите Шефове как броя транзакции расте, а натоварването в БД почти не се променя. Има и месеци когато натоварването видимо намалява - чудесен пример за оптимизации. Примерно когато пуснахме result cache на някои заявки, веднага се видя в графиката; оптимизацията на процедурата за събиране на статистики също се усети. Добрите администратори винаги имат проблема, че тяхната работа не се вижда от мениджмънта, защото липсата на проблеми е трудно измерима. Една такава графика говори на език, познат за хората, които определят заплати и позиции.

Интересна графика се получава и от "първата производна" - нарастването за една година. "През януари 2014 сме направили Х% повече плащания спрямо януари 2013, а натоварването на на сървърите е нарастнало само с Y%". Всеки мениджър, който знае цената на Oracle licenses (per CPU) ще оцени такъв довод.

P.S. Версия на тази заявка, подходяща за RAC бази има тук

 Posted by at 9:36