Re: Patch dla mfs.spec
W dniu 11 marca 2013 20:33 użytkownik Paweł Kośka pa...@viop.pl napisał: Czy przeinstalowanie całego mojego środowiska na np. ubuntu i wykonywanie takich samych testów uruchamiając poldka w chroocie ma sens? Uruchomienie poldka z aktualnego th i tego nowego z th-test .. i zobaczenie jak się tam zachowa? Może coś mi poleciało jeszcze nie tak przy kompilacji MooseFS na PLD? No i przeinstalowałem teraz klient jest na Ubuntu. Ten niepoprawiony poldek uruchomiony w chroocie zachowuje się tak samo. Jak zasoby mfs są montowane jako / jest OK Jak jest montowany podkatalog (-S /mfstest) to się wiesza, tak samo jak wcześniej załączałem log. Qboosh jak u Ciebie to działa poprawnie, to znaczy się że coś nie tak z moim Masterem na Arch Linux, ew. chunkserverami na PLD. Jeszcze spróbuje w wolnej chwili to na ubuntu przerobić. Bo już nie mam pojęcia czemu to się różnie może zachowywać w zależności jak montuje zasoby moosefs. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
OT: jak namierzyć przyczynę wysokiego load?
Witam, Od jakiegoś czasu walczę z niekończącymi się alertami o wysokim loadzie na różnych serwerach. Konkretniej - to na dwóch, które działają w tandemie i mają spięte bazy mysql (replikacja) oraz filesystemy /home (DRBD+OCFS2). Bardzo często mam sytuacje takie, że load rośnie nagle do wysokich poziomów rzędu 50-60 - a gdy po 3 minutach dostaję info od nagiosa to load już jest niewielki lub ma wyraźną tendencję spadkową. Nie bardzo jestem w stanie namierzyć cokolwiek co by tu mogło wpływać na wysoki load. Owszem, ruch na serwerach jest (ale śmieszny w porównaniu z ich możliwościami), ale na pewno nic nie wchodzi na swapa - bo swapa nie ma :) top/vtop (serwery mają odpalone po kilka vserverów) nie pokazuje żadnych procesów które by mordowały sprzęt. Pamięć zapchana nie jest, iostat -x też nic specjalnego nie pokazuje poza 100% obciążeniem dla drbd0 (co ponoć jest normalne z racji metodologii pomiaru przez iostat). iotop też nie pokazuje żadnych morderczych procesów. A, i ważne: mimo wysokiego loadu wszystko działa dobrze - jedynie drażni alertami nagiosa... Jakiś pomysł jak namierzyć przyczynę? Co jeszcze dodatkowo sprawdzić? Pozdrawiam, -- Jacek Osiecki jos...@ceti.pl GG:3828944 I don't want something I need. I want something I want.___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: OT: jak namierzyć przyczynę wysokiego load?
On Tue, 12 Mar 2013 14:37:25 +0100 (CET) Jacek Osiecki jos...@hybrid.pl wrote: Witam, Od jakiegoś czasu walczę z niekończącymi się alertami o wysokim loadzie na różnych serwerach. Konkretniej - to na dwóch, które działają w tandemie i mają spięte bazy mysql (replikacja) oraz filesystemy /home (DRBD+OCFS2). Bardzo często mam sytuacje takie, że load rośnie nagle do wysokich poziomów rzędu 50-60 - a gdy po 3 minutach dostaję info od nagiosa to load już jest niewielki lub ma wyraźną tendencję spadkową. 'Load' mówi ile procesów w jednej chwili che coś od systemu. Jeżeli masz file-system na DRBD+OCFS, to wystarczy, że file-system przez chwilę będzie zatrzymany przez problemy z siecią, a już wszystkie procesy, które cokolwiek chcą tam zapisać (czy nawet odczytać, jeśli masz włączone atime) się zatrzymają w stanie 'D' i zaczną być wliczane do tego 'loadu'. Nie bardzo jestem w stanie namierzyć cokolwiek co by tu mogło wpływać na wysoki load. Stawiam na problemy z siecią i DRBD/OCFS. Jak rozumiem używasz DRBD w konfiguracji active-active. W takim przypadku nie może on zgłosić powodzenia żadnej operacji zapisu, póki nie dotrze ona do drugiej strony. Wystarczy strata pakietu, czy większe opóźnienie i już wszystkie procesy się zatrzymują. W przypadku OCFS dochodzą jeszcze blokady (DLM), które też są synchronizowane przez sieć. System może wydawać się działać normalnie, bo te opóźnienia mogą być, po uśrednieniu, niewiele większe od opóźnień w dostępie do zwykłego dysku twardego, ale procesy czekające na DRBD czy lock DLM dla systemu wyglądają trochę inaczej (przynajmniej takie mam wrażenie) – na dysk zwykle czekają w stanie 'S', na DRBD/lock w stanie 'D'. Pierwsze nie jest wliczane do load, drugie już tak. Co można z tym zrobić? - spróbować montować z noatime,nodiratime, żeby ograniczyć ilość zapisów/blokad – pogmerać z parametrami DRBD – sprawdzić połączenie sieciowe, o ile możliwe zrobić dedykowane dla DRBD i/lub dla klastra/DLM – poustawiać priorytety ruchu tak, żeby łącze nigdy nie było wysycone Pozdrowienia, Jacek ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: OT: jak namierzyć przyczynę wysokiego load?
On Tuesday 12 March 2013 14:57:13 Jacek Konieczny wrote: On Tue, 12 Mar 2013 14:37:25 +0100 (CET) Jacek Osiecki jos...@hybrid.pl wrote: Nie bardzo jestem w stanie namierzyć cokolwiek co by tu mogło wpływać na wysoki load. Stawiam na problemy z siecią i DRBD/OCFS. Jakiś pomysł jak namierzyć przyczynę? Co jeszcze dodatkowo sprawdzić? Ja bym proponował zalogowac stan procesów z szczytu loadu. Wtedy będzie mozna zwerfykować hipotezę. -- Mateusz Korniak (...) mam brata - poważny, domator, liczykrupa, hipokryta, pobożniś, krótko mówiąc - podpora społeczeństwa. Nikos Kazantzakis - Grek Zorba ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: rpm: pliterki changelogu z gita i pytanie o zmienną
On Sat, Mar 09, 2013 at 09:40:54AM +0100, Tomasz Pala wrote: Witam, dzisiaj zauważyłem i dla pewności sprawdziłem: ~: rpm -q --changelog ghostscript-x11 | enca 7bit ASCII characters ~: rpm -q --changelog ghostscript-x11 (również z | iconv --from-code=UTF8 --to-code=iso8859-2) * Wed Dec 12 2012 Jan R?korajski bagg...@pld-linux.org 4a35c1c * Sun Sep 09 2012 Arkadiusz Mi?kiewicz ar...@maven.pl 4fb9731 * Wed Feb 08 2012 Adam Go??biowski ad...@pld-linux.org 4427095 Co ciekawe: $ rpm -q --changelog ghostscript | enca Universal transformation format 8 bits; UTF-8 $ rpm -q --changelog ghostscript-x11 | enca 7bit ASCII characters $ rpm -q ghostscript ghostscript-x11 ghostscript-9.06-3.i686 ghostscript-x11-9.06-3.i686 Z dalszego śledztwa wychodzi mi, że rpm przekodowuje changelog do kodowania z LC_CTYPE w momencie budowania ale tylko dla podpakietów. W pakiecie głównym jest zawsze UTF-8. a przy okazji pytanie - w jaki sposób przekonać rpmbuild, aby przekazywał zmienną ze środowiska, konkretnie chodzi mi o CCACHE_DIR? Wychodzi mi, że zwykły sposób działa: CCACHE_DIR=cos rpmbuild -bb *spec -- Kacper ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Patch dla mfs.spec
On Mon, Mar 11, 2013 at 08:33:17PM +0100, Paweł Kośka wrote: W dniu 11 marca 2013 18:10 użytkownik Bartlomiej Zimon uz...@o2.pl napisał: No to fajnie, poldek naprawiony w th-test lezy, a my czekamy na feedback, czy juz jest ok :) Na pewno jest inaczej ;) upgrade zrobiony [root@pavetta services]# poldek --version poldek 0.30.0 (rc) Copyright (C) 2000-2007 Pawel A. Gajda m...@pld-linux.org This program may be freely redistributed under the terms of the GNU GPL v2 [root@pavetta services]# rpm -qa | grep poldek poldek-libs-0.30.0-1.rc7.1.x86_64 poldek-0.30.0-1.rc7.1.x86_64 No i teraz jeszcze raz testujemy: [root@pavetta services]# mfsmount /home/services/PLD/ -d -o mfsdebug -H 172.16.20.164 -S / http://pastebin.com/XFgXWpyq [root@pavetta services]# strace -o /tmp/test9.log poldek -v --noask -s PLD/mfstest/RPMS/ --mkidxz http://pastebin.com/CY3FVMTA I drugi test, montowanie podkatalogu [root@pavetta services]# mfsmount /home/services/PLD/ -d -o mfsdebug -H 172.16.20.164 -S /mfstest http://pastebin.com/y2rjPytr [root@pavetta services]# strace -o /tmp/test10.log poldek -v --noask -s PLD/RPMS/ --mkidxz http://pastebin.com/WWBUWfBa No to dalej coś źle z poldkiem, bo w logu jest dwa razy EPERM, a błąd zignorowany - brak(?) informacji na stderr, kod wyjścia 0. Błąd trudny do powtórzenia w normalnych warunkach (niepowodzenie odczytu po wcześniejszym udanym zapisie), ale jednak. Co do samego problemu z MFS-em - nie udało mi się powtórzyć. Może trochę różnią się warunki... Mógłbyś dać dostęp do tego swojego systemu (master + mount)? Kontakt na maila. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
[RescueCD] Beta 2013-03
Witam Przemieliłem rcd na podstawie aktualnego th. Dla zainteresowanych: http://rescuecd.pld-linux.org/beta/ bez większych zmian poza odświeżeniem pakietów z git. niestety paczki generlanie wzrosły - najbardziej kernel i firmware do niego, nie bawiłem się póki co w optymalizację zużycia pamięci 32 bit - potrzebuje 300MB by wstać ;( docelowo będę się starać by 256 wystarczyło 64 bit - by bujneło potrzebuje ok 800MB na VirtualBox wstaje - potestujcie u siebie ;) Pozdrawiam, -- Arkadiusz Patyk [areqpld-linux:org] [http://rescuecd.pld-linux.org/] [IRC:areq GG:1383 jid:arekpatyk:net] ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
