BG Development


Страници: (2) [1] 2   ( Първото ново мнение ) Reply to this topicStart new topicStart Poll

> бавна работа на postgresql 9.0
vandeto
Публикувано на: 04-01-2018, 13:50
Quote Post



Име:
Група: Потребител
Ранг: Редовен член

Мнения: 351
Регистриран на: 17.09.04



Здравейте, имам следния проблем използвам postgresql 9.0 (под windows) като използвам само select заявки към базИ с доста записи в някои таблици. големия проблем е, че нещо нечовешки затормозява базата на моменти тъй като една и съща заявка се изпълнява за 2-3-4 секунди но доста често същата минава за 4-5-6 дори и до 10-15 МИНУТИ. няколко пъти ми се случи да нямам свободни конекции към базата (ползваме 100) но това не е големия проблем. също така е важно да отбележа, че трети лица пишат доста интензивно в базата, едни от най натоварените таблици с по няколко милиона записа(достигат до 100тина) се пише на всеки 2 минутки, а в останалите.... понякога и по често инсърти, ъпдейти и т.н.

СЕГА.... търсих тук-там в нета, прегледах всякъкви опции да пусна за чакащи, блокирани и т.н. заявки когато моите селекти се бавят при изпълнение но така и не ги виждам pg_stat_activity виюто. въпроса ми е мога ли да разбера кое по дяволите се ебава с мен(понякога) и така и не минават заявките ми както нормално се случва това. дали честото писане в базата ъпдейтва индексите на таблиците често и дълго които ми се налага да ползвам, а и дали това съвпаднато със селекта ме кара да не мога да ги използвам или просто да чакам тяхното завършване...
дайте насока къде и какво да търся...
PMEmail Poster
Top
Bender
Публикувано на: 04-01-2018, 14:10
Quote Post



Име:
Група: Форумен член
Ранг: Почетен член

Мнения: 4993
Регистриран на: 19.06.14



1. Когато един съботен ден Той дойде в къщата на едного от фарисейските началници да яде хляб, ония, които бяха там, Го наблюдаваха;
2. и ето, застана пред Него един човек, болен от красник.
3. Иисус продума на законниците и фарисеите и рече: позволено ли е да се лекува в събота?
4. Те мълчаха. И като хвана болния, изцери го и отпрати.
5. След това им рече: кой от вас, ако осел или вол му падне в кладенец, няма веднага да го извади и в съботен ден?
6. И не можаха да Му отговорят на това.
7. А като забелязваше, как поканените избираха първите места, каза им притча:
8. кога те покани някой на сватба, не сядай на предно място, да не би някой между поканените от него да бъде по-почетен от тебе,
9. и да не би тоя, който е поканил тебе и него, дойде и ти каже: отстъпи на тогова място; и тогава ще отидеш засрамен да заемеш последното място.
10. Но, кога бъдеш поканен, иди и седни на последното място, та тоя, който те е поканил, като дойде, да ти каже: друже, премести се по-горе; тогава ще ти бъде чест пред насядалите с тебе;
11. защото всеки, който превъзнася себе си, ще бъде унизен; а който се смирява, ще бъде въздигнат.
12. А и на тогова, който Го бе поканил, рече: кога даваш обяд или вечеря, не кани приятелите си, нито братята си, нито роднините си, нито богати съседи, да не би да те поканят и те някога, и да получиш отплата.
13. Но, кога даваш гощавка, кани бедни, маломощни, хроми, слепи,
14. и ще бъдеш блажен, задето те не могат да ти се отплатят, понеже ще ти бъде отплатено, кога възкръснат праведните.
15. Като чу това един от насядалите с Него на трапезата, рече Му: блажен е, който ще яде хляб в царството Божие!
16. А Той му отвърна: един човек приготви голяма вечеря и покани мнозина;
17. и в часа за вечеря изпрати слугата си да каже на поканените: дойдете, понеже всичко е вече готово.
18. И почнаха всички като сговорени да се извиняват. Първият му рече: купих си нива и ще трябва да отида да я видя; моля те, извини ме.
19. Другият рече: купих си пет рала волове и отивам да ги опитам; моля те, извини ме.
20. Третият рече: ожених се, и затова не мога да дойда.
21. И като се върна, слугата обади това на господаря си. Тогава стопанинът на къщата се разсърди и рече на слугата си: излез по-скоро по стъгдите и улиците на града и доведи тук бедните, маломощните, хромите и слепите.
22. И рече слугата: господарю, извършено е, както заповяда, и още място има.
23. И рече господарят на слугата: излез по друмища и плетища, и, колкото намериш, накарай ги да влязат, за да се напълни къщата ми.
24. Защото, казвам ви: никой от поканените няма да вкуси от вечерята ми. Понеже мнозина са звани, а малцина - избрани.
25. С Него вървеше множество народ, а Той се обърна и им рече:
26. ако някой дохожда при Мене, и не намрази баща си и майка си, жена си и децата си, братята и сестрите си, та дори и самия си живот, той не може да бъде Мой ученик;
27. и който не носи кръста си, а върви след Мене, не може да бъде Мой ученик.
28. Защото кой от вас, кога иска да съгради кула, не ще седне първом да пресметне разноските, дали има, каквото е нужно за доизкарването й,
29. та, кога тури основите и не може да я доизкара, да не би някак да почнат да му се смеят всички, които гледат,
30. и да казват: тоя човек почна да строи, и не можа да доизкара?
31. Или кой цар, отивайки на война срещу друг цар, не ще седне да се посъветва първом, дали може с десет хиляди да противостои на оногова, който иде срещу него с двайсет хиляди?
32. Инак, докато е онзи още далеч, той ще проводи при него пратеници да моли за мир.
33. Тъй, прочее, всеки от вас, който се не отрече от всичко, що има, не може да бъде Мой ученик.
34. Солта е добро нещо: но, ако солта изгуби сила, с какво ще бъде подправена?
35. Нито за земя, нито за тор е годна; изхвърлят я навън. Който има уши да слуша, нека слуша!



Това мнение е било редактирано от Bender на 07-01-2018, 20:45
PM
Top
Golden Gega
Публикувано на: 04-01-2018, 16:50
Quote Post



Име:
Група: Потребител
Ранг: Старо куче

Мнения: 673
Регистриран на: 04.06.10



PMEmail Poster
Top
Lachezar
  Публикувано на: 04-01-2018, 17:23
Quote Post



Име: Лъчезар Добрев
Група: Потребител
Ранг: Почетен член

Мнения: 2646
Регистриран на: 10.11.04



Ако ми се случи подобна ситуация ще заподозря ключалка.
В такива случаи изпълнявам един:
SQL
SELECT * FROM pg_stat_activity

Вътре се виждат всички текущи връзки, като преглеждам първо за "waiting", които са висящите процеси (чакащите), и "state", където се вижда дали процеса използва транзакция ('idle in transaction') или не.

После обръщам внимание на:
SQL
SELECT * FROM pg_locks

и търся тези, които не са "granted".

Но панацея няма. Анализа на това какво се случва и защо се случва често си е трудна задача.


--------------------
И'м ватцхинг ъоу...
PMUsers Website
Top
vandeto
Публикувано на: 04-01-2018, 17:34
Quote Post



Име:
Група: Потребител
Ранг: Редовен член

Мнения: 351
Регистриран на: 17.09.04



QUOTE (Golden Gega @ 04-01-2018, 16:50)
http://opm.io/

мерси но виждам, че е за линукс и иска psql 9.3 a аз ползвам 9.0 и е отседнало на windows-ка боза(извинявам се на феновете му) но за сървър....
PMEmail Poster
Top
vandeto
Публикувано на: 04-01-2018, 17:45
Quote Post



Име:
Група: Потребител
Ранг: Редовен член

Мнения: 351
Регистриран на: 17.09.04



QUOTE (Lachezar @ 04-01-2018, 17:23)
Ако ми се случи подобна ситуация ще заподозря ключалка.
В такива случаи изпълнявам един:
SQL
SELECT * FROM pg_stat_activity

Вътре се виждат всички текущи връзки, като преглеждам първо за "waiting", които са висящите процеси (чакащите), и "state", където се вижда дали процеса използва транзакция ('idle in transaction') или не.

После обръщам внимание на:
SQL
SELECT * FROM pg_locks

и търся тези, които не са "granted".

Но панацея няма. Анализа на това какво се случва и защо се случва често си е трудна задача.

не съм спрял да ги гледам, в pg_stat_activity всички "waiting" редове са false a "current_query" са само idle и чат пат по някой инсерт и ъпдейт от хората които тъпчат базата. В pg_locks ако говориш за "locktype"-a няма нито едно "granted" но там няма много записи, варират от 5 до 30... ще проследя ИД на базите и ще видя кои са и какво се случва но статусите са главно "relation, tranzactionid, virtualxid"...
а и сега констатирах, че базата е станала 140ГБ... за месец и половина icon_smile.gif .... какво ще правим след година... две...
PMEmail Poster
Top
Golden Gega
Публикувано на: 04-01-2018, 17:52
Quote Post



Име:
Група: Потребител
Ранг: Старо куче

Мнения: 673
Регистриран на: 04.06.10



Като начало ако се знаят проблемните заявки е добре да се пускат с dirty read - Read uncommitted
Ако проблема продължава значи не са заключвания.
Пускай EXPLAIN ANALYZE и дай да гледаме резултата. Виж и дали има свободна RAM на сървъра, да не се окаже проблем с кеширането.
Като видим тия неща можем да продължим с гадаенето.
PMEmail Poster
Top
vandeto
Публикувано на: 04-01-2018, 18:00
Quote Post



Име:
Група: Потребител
Ранг: Редовен член

Мнения: 351
Регистриран на: 17.09.04



QUOTE (Golden Gega @ 04-01-2018, 17:52)
Като начало ако се знаят проблемните заявки е добре да се пускат с dirty read - Read uncommitted
Ако проблема продължава значи не са заключвания.
Пускай EXPLAIN ANALYZE и дай да гледаме резултата. Виж и дали има свободна RAM на сървъра, да не се окаже проблем с кеширането.
Като видим тия неща можем да продължим с гадаенето.

EXPLAIN ANALYZE на заявките ми няма проблем, както казах аз само чета но има други които пишат и предполагам ще трябва да се изследват те. РАМ има, яде окло 3 от 8ГБ цялата система, процесора сега се е кротнал, по 0,XX процента на процес но в някои моменти стигаше до 20-25% за един процес, рядко толко и за втори а останали седяха на около 0.xx-1%. Но днес е сравнително кротко и не мога да анализирам с проблемен сървър, а знам, че това ще е момeтно състояние и скоро мизерията ще тръгне отново...
PMEmail Poster
Top
ici
Публикувано на: 04-01-2018, 19:37
Quote Post


Group Icon
Име: Ивайло Илчев ики
Група: VIP
Ранг: Почетен член

Мнения: 14957
Регистриран на: 06.06.04



Във postgresql.conf дали няма разрешен autovacuum? С какво се достъпва базата? Някъ'в ORM, ODBC?


--------------------
Everything you can imagine is real. Pablo Picasso
PMEmail PosterUsers Website
Top
Lachezar
Публикувано на: 04-01-2018, 19:55
Quote Post



Име: Лъчезар Добрев
Група: Потребител
Ранг: Почетен член

Мнения: 2646
Регистриран на: 10.11.04



QUOTE (vandeto @ 04-01-2018, 17:45)
не съм спрял да ги гледам, в pg_stat_activity всички "waiting" редове са false a "current_query" са само idle и чат пат по някой инсерт и ъпдейт от хората които тъпчат базата. В pg_locks ако говориш за "locktype"-a няма нито едно "granted" но там няма много записи, варират от 5 до 30... ще проследя ИД на базите и ще видя кои са и какво се случва но статусите са главно "relation, tranzactionid, virtualxid"...
а и сега констатирах, че базата е станала 140ГБ... за месец и половина icon_smile.gif .... какво ще правим след година... две...

Това трябва да го правиш когато забележиш, че се е замотала работата, след като отпусне няма никакъв смисъл.
Под "waiting" имам предвид редовете в pg_stat_activity, където стойността на колоната "waiting" е "true".

За pg_locks трябва да се гледат редовете, където стойността на колоната "granted" е "false".

Това всичко има смисъл само в реално време, когато се случва проблема. Тези таблици са активни, а не исторически.

Редакция:
Също така трябва да наблюдаваш натоварването на дисковете и мрежата. Имал съм случаи, в които голяма заявка минава бързо, но данните се точат много време просто защото са много.

Това мнение е било редактирано от Lachezar на 04-01-2018, 19:57


--------------------
И'м ватцхинг ъоу...
PMUsers Website
Top
1 потребители преглеждат тази тема в момента (1 гости, 0 анонимни потребители)
Потребители, преглеждащи темата в момента:

Topic Options Страници: (2) [1] 2  Reply to this topicStart new topicStart Poll

 


Copyright © 2003-2015 | BG Development | All Rights Reserved
RSS 2.0