Lipiec 2004 - lms - lists.lms.org.pl

Re: Patch do bledu w LMS-MGC - nieprawidlowe pobieranie predkosci z bazy
by Łukasz Jarosław Mozer 14 Lip '04

14 Lip '04

Witam. W liście z dnia 13 lipca 2004 (20:03:13) można przeczytać: > Witajcie, > Pisalem niedawno o bledzie, wreszcie udalo mi sie znalezc troche czasu > i go wytropilem :) > W momencie kiedy uzytkownik ma datefrom, a nie ma dateto, to nie wyciaga > predkosci z bazy, wiec predkosc jest null. > A oto patch do aktualnej wersji: Na przyszłość, używaj opcji -u do diffa. -- Łukasz Jarosław Mozer http://www.baseciq.org mailto: lukasz(a)rulez.pl

1 0

Re: Drobny test mysql vs postgres
by A.L.E.C 14 Lip '04

14 Lip '04

Tomasz Chilinski wrote: > Warning: pg_query(): Query failed: ERROR: value "3330694606" is out > of range for type integer > in /var/www/localhost/htdocs/lms/lib/LMSDB_driver_postgres.class.php > on line 82 albo masz usera ściągającego 3 GB danych dziennie, albo zapisujesz do bazy bity. Chyba jednak trzeba zmienić typ pola na bigint. >> $this->DB->BeginTrans(); >> a na końcu pliku >> $this->DB->CommitTrans(); > > Przecież to jest w tym pliku. no tak, sam zapomniałem co tam wpisałem, ale to wyjaśnia sprawę długiego czasu wykonania kompaktowania na postgresie, bo w przypadku błędów następuje rollback i to trwa. Prośba do Rafała, zmień typ pól i wykonaj test ponownie. -- Pozdrawiam Aleksander 'A.L.E.C' Machniak http://alec.pl gg-2275252 Lan Management System Developer http://lms.rulez.pl

1 0

Re: Drobny test mysql vs postgres
by Tomasz Chilinski 14 Lip '04

14 Lip '04

On Wed, 14 Jul 2004 07:58:24 +0200, A.L.E.C wrote > czy to wersja cvs'owa?, mógłbyś podać te błędy? Kompaktowanie bazy danych Przed kompaktowaniem w bazie jest 149899 rekordów. 'ADAM' : 2 - usuniętych, 2 - wstawionych 'ADAMEK' : 0 - usuniętych, 0 - wstawionych 'AGAMAL' : Warning: pg_query(): Query failed: ERROR: value "3330694606" is out of range for type integer in /var/www/localhost/htdocs/lms/lib/LMSDB_driver_postgres.class.php on line 82 Warning: pg_query(): Query failed: ERROR: current transaction is aborted, commands ignored until end of transaction block in /var/www/localhost/htdocs/lms/lib/LMSDB_driver_postgres.class.php on line 82 itd. Z tego co widzę za małą szerokość ma jedno z pół w tablicy stąd problem... > czy mógłbyś przeprowadzić jeszcze raz test dla postgresa, ale > modyfikując plik modules/trafficdbcompact.php dodając na początku > $this->DB->BeginTrans(); > a na końcu pliku > $this->DB->CommitTrans(); Przecież to jest w tym pliku. > Pozdrawiam > Aleksander 'A.L.E.C' Machniak http://alec.pl gg-2275252 Pozdrawiam Tomasz Chiliński

1 0

Re: Drobny test mysql vs postgres
by A.L.E.C 14 Lip '04

14 Lip '04

Rafal Ramocki wrote: > Ale.... > Statystyki > Mysql 4s, strona po 10-u > Postgres 12s strona po 17-u > Kompaktacja > mysql niecale 2.5 min > Postgres 7min i kompaktacja odbyla sie z bledami. Nie za bardzo wiem > o co chodzi. Dziaj nie che mi sie jeszcze raz jej wykonywac - ide > spac, ale nie przyjemnie to wygladalo. Bledy pochodzily bezposrednio > z zapytan postgresa. czy to wersja cvs'owa?, mógłbyś podać te błędy? > Dziwne jest to ze na zapytaniach ze statystyk postgres jest o wiele > slabszy. Nic ja ide spac. czy mógłbyś przeprowadzić jeszcze raz test dla postgresa, ale modyfikując plik modules/trafficdbcompact.php dodając na początku $this->DB->BeginTrans(); a na końcu pliku $this->DB->CommitTrans(); niestety nie mam bazy na której mógłbym to sprawdzić. Natomiast jeśli chodzi o listę userów, to widać wyższość postgresa w zapytaniach ze złączeniami. W statystykach jest dużo prostych selectów i insertów (inserty są w mysqlu z zasady szybsze) a danych bardzo dużo i widać nawiększe różnice. -- Pozdrawiam Aleksander 'A.L.E.C' Machniak http://alec.pl gg-2275252 Lan Management System Developer http://lms.rulez.pl

1 0

Drobny test mysql vs postgres
by Rafal Ramocki 14 Lip '04

14 Lip '04

Witam! Zastanawiam sie nad migracja z bazy mysql do postgresa. Nie byl bym soba gdybym wczensiej nie przeprowdzil pewnych badan. :) Przeprowadzalem dzisaj male testy wydajnosci LMS'a na dwoch bazach danych. Nie bawilem sie w dokladny, milisekundowy pomiar czasu. Baza jest na tyle duza ze roznice widac w sekundach a nie w milisekundach. No i baza jest rzeczywista pracujaca. Wykozystalem do tego opere, bo ladnie pokazuje ile czasu uplynelo od tego jak kliknale, przez otrzymanie pierwszych danych, do zakonczenia ladowania. Test wykonalem na 3 roznych operacjach. 1. Wyswietlanie pelnej listy userow. (okolo 400-u) 2. Wyswietlanie statystyk z ostatnich 30 dni 3. Kompaktowanie statystyk. Miezylem czas od klikniecia do uzyskania pierwszych danych i od klikniecia do skonczenia ladowania ( tak na wszelki wypadek) Oto co otrzymalem Lista uzytkownikow Mysql 6 do 8s przetwarzanie rzadania, strona zaladowana po 28s. Postgres niecala 1s przetwarzanie, strona zaladowana po 18s Ale.... Statystyki Mysql 4s, strona po 10-u Postgres 12s strona po 17-u Kompaktacja mysql niecale 2.5 min Postgres 7min i kompaktacja odbyla sie z bledami. Nie za bardzo wiem o co chodzi. Dziaj nie che mi sie jeszcze raz jej wykonywac - ide spac, ale nie przyjemnie to wygladalo. Bledy pochodzily bezposrednio z zapytan postgresa. Dziwne jest to ze na zapytaniach ze statystyk postgres jest o wiele slabszy. Nic ja ide spac. z powazaniem Rafal Ramocki

1 0

Re: tc jeszcze raz "[dot]"@go2.pl, pl@go2.pl
by Tomasz Chilinski 13 Lip '04

13 Lip '04

On Tue, 13 Jul 2004 20:07:40 +0200, Cody wrote > Jeśli nawet wykorzystujesz fwmark, to jak zrobiłeś powiązanie > fwmarka z tym, że z bazy jest brany ip + upload+download rate. Jeśli > nawet potem robisz cięcie (czym htb?) wykorzystując fwmark, to skąd > masz informację jaki mark ma dany ip ? Robisz to od razu tzn: w > jednym skrypcie zakładasz marka na ip z numerem (kolejnym z rzędu ?), > przydzielasz kolejki dla tego marka ? Co kiedy gdy następuje zmiana > parametrów ? Czy można zrobić cięcie ruchu wychodzącego ( do netu) > tak samo jak dla przychodzącego ( a idącego do lanu ) tyle że na > interfejsie zewnętrznym pomimo tego że jest masqerada ? http://netfilter.org Przejrzyj patch-o-matica oraz archiwum listy LARTC. > Dzęki za odpowiedź. > Cody Pozdrawiam Tomasz Chiliński

1 0

Re: Patch do bledu w LMS-MGC - nieprawidlowe pobieranie predkosci z bazy
by Przemek SAKO Galczewski 13 Lip '04

13 Lip '04

Hello A.L.E.C, Tuesday, July 13, 2004, 9:02:41 PM, you wrote: ALEC> Przemek SAKO Galczewski wrote: >> ! $dbq = $dbase->prepare("SELECT userid, SUM(uprate) AS >> uprate, SUM(downrate) AS downrate FROM assignments, >> users, tariffs WHERE users.id = userid AND deleted = 0 AND tariffid = >> tariffs.id AND (datefrom <= $utsfmt OR datefrom = 0) AND (dateto > >> $utsfmt OR dateto = 0) AND (datefrom <= dateto OR dateto = 0) GROUP >> BY userid"); $dbq->execute(); ALEC> dzieki, ale zdaje sie, ze wystarczy, tak jak jest w lms-payments: ALEC> WHERE users.id = userid AND deleted = 0 AND tariffid = ALEC> tariffs.id AND (datefrom <= $utsfmt OR datefrom = 0) AND (dateto > ALEC> $utsfmt OR dateto = 0) GROUP BY userid mozna i tak, sorry, ale nie optymalizowalem tego i nie zagladalem do payments, po prostu poprawilem buga analogicznie do skladni wykorzystywanej w mgc. najwazniejsze, ze jeden bug mniej :) -- Best regards, Przemek mailto:sako@infinity.waw.pl

1 0

Re: tc jeszcze raz "[dot]"@go2.pl, pl@go2.pl
by Przemysław 'Repcio' Gubernat 13 Lip '04

13 Lip '04

On Tue, Jul 13, 2004 at 08:07:40PM +0200, Cody wrote: > >Osobiście używam ograniczania na WAN używając fwmark (a gdzie się na > >NAT'a > >przestawiam dalej i ograniczam po IP), mam jedno rozwiązanie z IMQ. > > > > Jeśli nawet wykorzystujesz fwmark, to jak zrobiłeś powiązanie fwmarka z > tym, że z bazy jest brany ip + upload+download rate. Jeśli nawet potem > robisz cięcie (czym htb?) wykorzystując fwmark, to skąd masz informację [..] Skryptem wyrzucam z bazy lms'a do pliku w formacie %ID %IP %UP %DOWN a następnie na bazując na tym pliku generuję właściwy skrypt do htb. fwmarka "generuję" bazując na ID użytkownika/kompa (albo tym z LMS'a albo po prostu jako kolejny numerej wpisu w pliku) > Czy można zrobić cięcie ruchu wychodzącego ( do netu) tak samo jak dla > przychodzącego ( a idącego do lanu ) tyle że na interfejsie zewnętrznym > pomimo tego że jest masqerada ? > Dokładnie tak to robię. -- Szanuj admina swego, możesz mieć gorszego..... (c) 2000 Przemysław Gubernat +-=-=- Przemysław Gubernat <repcio(a)repcio.net> -=-=-=-=-=-=-+ | System Administrator @ Repcio.NET | | Jestem twoim ostatecznym rozwiązaniem ! | +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+

1 0

Re: lms.nodes...name varchar(16) NOT NULL default ''...
by lukas 13 Lip '04

13 Lip '04

ALEC> w zasadzie to chyba tylko w modules/nodeadd.php jest sprawdzana długość ALEC> nazwy hosta Hmm. Czyli powinno mi wystarczyć w sumie zmienienie struktury bazy bo dane userów wprowadzam własnymi zapytaniami więc tylko to mnie ogranicza a ciekawy byłem czy gdzieś głębiej będzie z tym problem. Jakby nie było to poprostu to sprawdzę -------------------- Łukasz Wojciechowski

1 0

Re: Patch do bledu w LMS-MGC - nieprawidlowe pobieranie predkosci z bazy
by A.L.E.C 13 Lip '04

13 Lip '04

Przemek SAKO Galczewski wrote: > ! $dbq = $dbase->prepare("SELECT userid, SUM(uprate) AS > uprate, SUM(downrate) AS downrate FROM assignments, > users, tariffs WHERE users.id = userid AND deleted = 0 AND tariffid = > tariffs.id AND (datefrom <= $utsfmt OR datefrom = 0) AND (dateto > > $utsfmt OR dateto = 0) AND (datefrom <= dateto OR dateto = 0) GROUP > BY userid"); $dbq->execute(); dzieki, ale zdaje sie, ze wystarczy, tak jak jest w lms-payments: WHERE users.id = userid AND deleted = 0 AND tariffid = tariffs.id AND (datefrom <= $utsfmt OR datefrom = 0) AND (dateto > $utsfmt OR dateto = 0) GROUP BY userid -- Aleksander 'A.L.E.C' Machniak http://alec.pl gg-2275252 Lan Management System Developer http://lms.rulez.pl

1 0