4P dziwnie wolno działa / zalicza zawiechy od kilku dni

0

No ale po co maszyna? Jeśli jest zapas CPU, RAM i dysk też wyrabia, to moim zdaniem nie sprzęt jest problemem.

0
Adam Boduch napisał(a):

Chyba będzie potrzebna nowa maszyna na bazę.

Czyli wraca temat płatnych kont, trzeba w końcu uświadomić iż korzystanie z forum i obcowanie z elitą IT to przywilej.

1

Co tam u bazy słychać? Wszystko już śmiga pięknie?

Czytam sobie właśnie "Mastering PostgreSQL 12" i tam jest kilka ciekawych wzmianek o VACUUM:

Instead of the normal VACUUM, you can also use VACUUM FULL. However, I really want to
point out that VACUUM FULL actually locks the table and rewrites the entire relation. (...) To get rid of VACUUM FULL, I recommend that you check out pg_squeeze (https://www.cybertec-postgresql.com/en/introducing-pg_squeeze-a-postgresql-extension-to-auto-rebuild-bloated-tables/), which can rewrite a table without blocking writes.

.

This also implies that really long transactions can postpone cleanup for quite some time.
The logical consequence is table bloat. Tables will grow beyond proportion, and
performance will tend to go downhill. Fortunately, starting with PostgreSQL 9.6, the
database has a nice feature that allows the administrator to intelligently limit the duration
of a transaction. To limit the lifetime of snapshots, you can make use of a setting in PostgreSQL's config
file, postgresql.conf, which has all of the configuration parameters that are needed for
this: old_snapshot_threshold

.

One more way to improve on VACUUM is to use SKIP_LOCKED: the idea here is to make sure
that VACUUM does not harm concurrency. If SKIP_LOCKED is used, VACUUM will
automatically skip over relations, which cannot instantly be locked, thus avoiding conflict
resolution. This kind of feature can be very useful in the event of heavy concurrency.

plus jeden parametr który warto zmienić jak baza jest na ssd

random_page_cost = 4: If PostgreSQL uses an index, there is usually a lot of
random I/O involved. On traditional spinning disks, random reads are much
more important than sequential reads, so PostgreSQL will account for them
accordingly. Note that, on SSDs, the difference between random and sequential
reads does not exist anymore, so it can make sense to set random_page_cost =
1 in the postgresql.conf file.

0

Będzie migracja na nowy serwer. Jeszcze nie wszystko śmiga tak jak powinno. Czasem są lagi szczególnie podczas zapytań typu INSERT.

2

WWW jest już na nowym serwerze, baza również. Póki co są domyślnie ustawienia vacuum. Zobaczymy jak to będzie się sprawować.

1

@Adam Boduch: próbowałem usunąć dziś ten post i otrzymałem taki błąd, jak poniżej. Może ma to związek z przeniesieniem bazy czy https://4programmers.net/uploads/attachment/5e/5e13af3305708.pngmers.net/uploads/attachment/5e/5e13af3305708.png)


PS. @cerrato też mówił, że chciał coś usunąć, i nic z tego.

1

Potwierdzam, sam też to zauważyłem w innym wątku, ale nie zgłaszałem, bo mi się nie chciało (proszę docenić szczerość :D ) a poza tym mój post był którymś w wątku, po nim było kilka kolejnych. Wpis Silva w chwili, w której próbował go skasować, był ostatnim. Zresztą i tak powinien być komunikat o błędzie, a nie error - więc coś nie działa ewidentnie.

0

Jeszcze jedno dziwne zachowanie po zmianie serwera. Chciałem na PW wkleić obrazek. Tak, jak zawsze - mam go w schowku, w treści wiadomości robię Ctrl-V i dostaję to, co widać poniżej:

screenshot-20200107095706.png

0

Może uprawnienia w katalogach, po przenosinach, zapomniano zmienić?

0

Być może, ale w przypadku wklejania zdjęcia w treści posta wszystko działa (co zresztą widać powyżej), a problem jedynie występuje na PW

2

Pliki są teraz w S3 więc na pewno nie jest to kwestia uprawnień. Widzę w logach błąd z tym związany. Dzisiaj sprawdzę o co może chodzić...

1

@Adam Boduch: ja mam jeszcze jeden problem. Od kilku dni, w losowych momentach, po załadowaniu strony całość zamula – przeglądarka żre całą moc jednego jajka CPU. Wygląda to jak problem ze skryptami. Ze dwa razy w ostatnich dniach mi się to zdarzyło.

Sytuacja miała miejsce, gdy mając otwartą jedną zakładkę i pisząc odpowiedź w jakimś wątku przychodzi powiadomienie. Następnie rozwinąłem listę spod dzwoneczka, otworzyłem powiadomienie w nowej karcie, sprawdziłem o co chodzi, następnie zamknąłem tę kartę i wróciłem do pisania. Przeglądarka tak zamulała, że nie dało się normalnie pisać dalszej części odpowiedzi – wstukiwane literki pojawiały się powolutku (i cała nawigacja w polu edycyjnym, czyli przesuwanie kursora tekstowego, kasowanie znaków itd.), góra dwie na sekundę. Odświeżenie strony likwidowało zamułę.


Najpewniej w najbliższym czasie znów mi się przydarzy, więc dokładnie się przyjrzę sprawie – może będę w stanie napisać coś więcej o tym problemie.

Edit: znów napotkałem ten problem i wiem co jest jego przyczyną – kliknięcie w przycisk oznaczania powiadomień jako przeczytanych, na rozwijalnej liście powiadomień. Sprawa wygląda jeszcze gorzej, bo oprócz zjadania mocy CPU, powoli i bez końca rośnie zużycie pamięci. Sprawdzę na innej przeglądarce czy ten problem też tam istnieje.

Edit 2: sprawdziłem teraz i pod inną przeglądarką jest tak samo. Różnica jednak polega na tym, że na Firefoksie ssanie rozpoczyna się od momentu rozwinięcia listy powiadomień spod dzwoneczka i nie ma to żadnego związku z tym czy są nowe powiadmoenia czy nie. Po prostu rozwijam listę i się zaczyna.

0

Czy jak rozumiem, wystarczy otworzyć listę powiadomień aby zobaczyć postępujący wyciek pamięci? Niestety nie mogę tego odwzorować. Czy ktoś jeszcze może to potwierdzić? Zrób taki eksperyment. Utwórz Firefox, wejdź do narzędzi deweloperskich (Ctrl+Shift+I). Tam jest zakładka Memory. Jest też przycisk Snapshot który umożliwia pobranie ilości pamięci zalakowanej przez daną stronę. Możesz co jakiś czas robić snapshoty aby zobaczyć jak zmienia się zużycie w czasie.

screenshot-20200107203126.png

Zrobiłem 3 snapshoty. Pierwszy po otwarciu strony, kolejny po otwarciu listy powiadomień. Ostatni po kilku minutach bezczynności (lista powiadomień była załadowana).

@cerrato: wklejanie screenów z wiadomościach powinno już działac.

2

@Adam Boduch: zrobiłem jak zasugerowałeś:

memory.png

Jak widać strona z czasem puchnie, co prawda nieznacznie, ale puchnie. Najdziwniejsze jest to, że o ile pamięć zarezerowana dla strony rośnie raptem o kilka megabajtów w czasie minuty, tak pamięć zajmowana przez przeglądarkę (sprawdzana w systemowym menedżerze zadań) puchnie w tempie około 300MB na minutę. :/

Jutro sprawdzę jak to wygląda na innym komputerze, z Win7 i najnowszym Firefox.

0

300 mb na minutę? O kurde. U mnie cały czas w okolicy 200 mb. Czy masz włączone jakiekolwiek dodatki do Firefoxa?

0
Adam Boduch napisał(a):

300 mb na minutę?

Dokładnie, ale to nie jest rozmiar pamięci zajmowanej przez przeglądarkę czy stronę, a przyrost zużycia pamięci (przeglądarka ma zarezerowane 450MB, rozwijam powiadomienia, a po minucie mam już ponad 700MB). W takiej sytuacji po kilkunastu minutach mojej bezczynności przeglądarka pożre całą dostępną pamięć i wysypie się razem z systemem.

Czy masz włączone jakiekolwiek dodatki do Firefoxa?

Bloker reklam i wtyczkę do wideo, jednak ich wyłączenie niczego nie zmienia. Przy czym klasyczna Opera też ma z tym problem i też zaczyna zjadać pamięć, więc raczej na pewno nie jest problem związany z konkretną przeglądarką.

1

To chyba musisz mieć jakiegoś babola, może coś z FF, u mnie na FF win8.1 15-20MB niezależnie czy z qblock włączony czy nie.

3

Może nie tak drastycznie, ale rzeczywiście pozostawienie strony samej sobie sprawia, że konsumpcja pamięci wzrasta

  1. screenshot-20200109123931.png
  2. screenshot-20200109123951.png
  3. screenshot-20200109124005.png
    Ale jak zostawiłem to na chwilę, poklikałem po innych stronach, to spadło (nie wiem, czy ma to związek z tym, że menu powiadomień było zamknięte)
  4. screenshot-20200109124322.png
0

Nie za bardzo po prostu widzę związek pomiędzy otwartą listą powiadomień a rosnącym zużyciem pamięci.

To ciekawe @Marooned co pokazałeś. Jedyne co mi przychodzi do głowy to ten kod (https://github.com/adam-boduch/coyote/blob/master/resources/assets/js/components/date.js) który co 30 sekund zmienia DOM odświeżając czas na stronie.

0

To ja sobie znowu odświeżę ten wątek :(

Czy zauważyliście, że od wczoraj powiadomienia są jakieś takie opóźnione, od kliknięcia dzwonka do pokazania listy mijają 2-3 sekundy (nie zawsze, ale coraz częściej)?

1

Włączyłem logowanie wolnych zapytań SQL, może się czegoś dowiedzieć.

2

Tez przed chwilą miałem laga przy generowaniu listy powiadomień. Ustawiłem logowanie wolnych zapytań (+100 ms) i kilka się powtarza. Są to albo COUNT() na tabeli, albo jakieś zapytania z wielkim OFFSET. Jedno już zoptymalizowałem. W związku z powiadomieniami, nie ma nic w logach.

0

Okazało się że tym razem problemem była nie baza, a zbyta mała liczba procesów php-fpm. Podkręciłem nieco konfiguracje. Zobaczymy czy będzie lepiej.

PS. Przynajmniej nie ma już problemów z zapytaniami INSERT czy UPDATE. Rzeczywiście, problem leżał w systemie plików na starym serwerze (był zbyt wolny).

0 użytkowników online, w tym zalogowanych: 0, gości: 0