Názory k článku Monitoring RDBMS PostgreSQL
-
Lukáš MalýZlatý podporovatelMoc pekne a hodnotne shrnuti na co se zamerit.
Pro Zabbix existuje cela rada sablon a scriptu, staci si vybrat to co nejlepe vyhovuje pozadavkum.
https://github.com/monitoringartist/zabbix-community-reposNebo ZShare
https://share.zabbix.com/search?searchword=PostgreSQL -
MP (neregistrovaný)
Tak nejak. Zakladni monitoring si udela kazdy admin sam. Ale pokud vyvojari nevyuzivaji nastroje, ktere jsou jiz nasazene, nebo nepouzivaji rozlisovaci parametry, tak s tim admin proste nic neudela. Ale nejhorsi je, ze pokud vyvojari vyvijeji primo na produkci, protoze to jinak neumeji nebo firma to tak chce, tak proste pulka tech analyz je k nicemu, pokud nelze rozlisit vliv dev/prod.
-
MP (neregistrovaný)
Tak instalace je ten nejmensi problem. Jenze ono to je komplexnejsi, vzhledem k tomu, ze se jedna o web aplikace a bezime vice psql serveru ruznych verzi.
1] neni vyresen prenos struktur/dat/(pripadna sanitizace) mezi prod-dev
2] neni vyreseno testovani webu z dev stanicTreba ten web, pokud dev webu bezi jen na produkci a vyzaduje psql backend a externi zdroje, tak jak ho asi tak propojit na nekolik dev psql. Ze by vyvojari prepinali ve skriptech pro vsechny najednou psql backend? To asi ne ze...
Jako jo, pokud dev bude delat jen backend, tak je to jednodussi, ale protoze je potreba to propojit i s temi, co delaji frontend, tak je to cele o naplanovani, realizovani. A to jeste k tomu preskolit vyvojare a nabourat vyvojovy proces cele firmy. Na jedne strane vyhoda, ze se to cele da postavit na zelene louce, na druhe strane nevyhoda, ze je nutne vymyslet cely ekosystem, aniz se vi, kde jsou zadrhele jednotlivych casti ekosystemu vyvoje...(ale to uz je jen povzdech...prace az nad hlavu)... -
MP (neregistrovaný)
Vagrant jsem trochu otukaval, ale priznam se, ze se mi nejak nepodarilo zprovoznit ani zakladni vec - prenos dat mezi PC a Vagrantem. Ale i u Vagrantu zustava stejna premisa - je nutne ten Vagrant nejak automatizovane nakonfigurovat a hlavne zajistit nejak obsah DB/web slozek. A na tom zatim stoji a pada veskere ma snaha o zmenu vyvojoveho procesu.
Treba by me zajimalo - jakym zpusobem je resen prenos struktury DB mezi dev-prod? Resp., pokud ma mit kazdy dev svoji verzi DB na PC, tak jak se pak merguji zmeny, pokud dela vice lidi na stejne casti DB?
-
V GD měl každý vývojář vlastní virtuální instanci (případně jich měl víc), která byla v podstatě trochu redukovanou kopií produkčních serverů (na virtuálu bylo možné pustit vybranou odpovídající část regresních testů) - jeho úkolem bylo doručit alter scripty, které se aplikovaly na preprod a na produkci. Teoreticky by si tyto skripty mohl každý aplikovat u sebe, ale to se většinou nedělo - pokud se mu virtuál rozjel vůči masteru, tak se virtuál zahodil a nechal si buildnout nový. Samozřejmě, že build, instalace a konfigurace sw byla automatická - pomocí puppetu, který jel vůči jeho větvi v gitu.
-
Ivan (neregistrovaný)
Treba by me zajimalo - jakym zpusobem je resen prenos struktury DB mezi dev-prod? Resp., pokud ma mit kazdy dev svoji verzi DB na PC, tak jak se pak merguji zmeny, pokud dela vice lidi na stejne casti DB?
Ve starych, ne-frikulinskych korporacich to byva tak, ze dev databaze je sdilenena (anebo je jich vice a jsou sdilene). Zmeny struktury provadi pouze architekt po dohode a ostatnimi. Vetsinou chcete aby za navrh schematu byl zodpovedny nekdo, kdo ma presah i do jinych technologii.
Pak jsou i na nastroje jako DBUnit, Liquibase anebo Flyway. Casto ale nakonec skoncite u klasickeho SQL, zvlast kdyz vyvijete na databazi ktera je zhruba stejne velika jako produkcni.
-
Ako doplnenie k tejto teme doporucujem velmi podareny clanok What PostgreSQL Tells You About Its Performance.
-
Což mi připomíná pracovní zkušenost s jednou 3rd-party DB aplikací, co máme v práci. Nativní klient pod Windows se přes ODBC baví s MSSQL. Ono se to průběžně vyvíjí, ale vyskytují se situace, kdy práce s klientem je subjektivně pomalá a některé "kroky" v uživatelském workflow váznou, ale fláká se CPU na klientu i na serveru, na serveru se flákají disky a MSSQL má přidělenu skoro celou RAMku, což je řádově tolik, že se mu do ní vejde celá DB. Asi ve dvou případech, když byla fakt krize, jsem zkusil i tutéž operaci v klientovi spuštěném přímo na DB serveru (měl jsem podezření na pomalou LANku) - výsledek byl přesně stejný. V noci pravidelně údržba - nějaká ta záloha a odvzdušnění následované přepočítáním indexů (protože v MSSQL je odvzdušnění bez přepočtu indexů sice možné, ale trestné). Z MSSQL se dají vyrazit i nějaké statistiky, ale skrz GUI nástroje od výrobce se člověk moc podrobností nedozví, po webu se válí nějaké skripty v MSSQL které by údajně mohly říct něco navrch - až na to, že skript resp. SQL příkaz je asi stránka textu a je třeba ho upravit na svou situaci. Věci určitě nepřispívá, že administraci MSSQL nepovažuju za svou hlavní náplň práce - inu jaký pán, takový krám... To je jenom takový povzdech, nežádám o pomoc, jsem tady off topic :-)
ČLÁNKY DO MAILU