Dlouhé načtení Nextcloudu

[darebacik]

Ked sa chcem prihlasit cez webovy (akykolvek) prehliadac do nextcloud, tak to trva neskutocne dlho (6-7 sekund). Tak isto ked chcem cez nextcloud otvorit dokument (libre office) na editaciu, tak to trva tiez 6-7 sekund. Nextcloud aj collabora su v podstate aktualne.

Ak sa chcem znova prihlasit (resp. prihlasuje ma automaticky), tak to uz ide normalne, aj dokumenty to otvara normalne. Aj ked zavrem prehliadac a znova otvorim, tak je to bez problemov. Ak nextcloud dlhsie nepouzivam, resp. chcem pristiupit do nextcloud po dlhsom case, alebo z ineho PC, tak zase musim cakat 6-7 sekund.

Prevazne pouzivam google chrome (problem je tiez v chromiu, FF, ale aj na mobilnom vivaldi, ine browsery nepouzivam) a viem ze existuje nejaka konzola cez F12. Avsak nemam ponatia co a kde sledovat aby som mohol zistit, preco a kde to drhne.

Aj som si zapol F12 v prehliadaci, ale nejak  tym logom nerozumiem.

[Reklama]

[Quba]

Ten nextcloud server provozujete sám? Pokud ano, provozujete na serveru ještě další služby? Ověřování uživatelů máte lokální nebo LDAP, ...? Podívejte se do logů, jestli někde něco nevázne.

Máte dost paměti? Dost výkonu procesoru? Připadá mi, že server musí odswapovat něco jiného na disk, než vše načte do RAM.

[Karmelos]

A nečekate jenom na na probuzení disku?

[Martin Oles]

Provozuji nextcloud. Co pozoruji, tak při přihlášení uživatele poměrně dost šahá na disk. Zkuste ověřit, že disk není problém? Je disk dost rychlý a hlavně v pořádku?

[Bukowski]

zkuste vymazat svoji IP z tabulky oc_bruteforce_attempts

[Reklama]

[darebacik]

Ten nextcloud server provozujete sám? Pokud ano, provozujete na serveru ještě další služby? Ověřování uživatelů máte lokální nebo LDAP, ...? Podívejte se do logů, jestli někde něco nevázne.

Máte dost paměti? Dost výkonu procesoru? Připadá mi, že server musí odswapovat něco jiného na disk, než vše načte do RAM.

Ano mam to v linuxovom kontajneri. Pridelene 4GB RAM a 2 cores (i5 10400). Myslem si ze po HW stranke je to OK. Disky su SSD WD (ZFS mirror), takze malo by to byt OK. Overovanie je lokalne. Zatial som jeden klient, je to len test. Postavene je to na debian netinst 11, aktualizovany apache2, php8.0 (predtym reverzny proxy nginx).

[Vantomas]

Možná bych to viděl na nějaký problém s DNS, kdy se to zkouší doptat na reverzní záznam a timeoutuje to. A jako další bych viděl problém v tom, že se automaticky nespouští cron skript a tak si to jako fallback spouští při requestech po nějaké době a trvá to, než se cron odbaví.

[Quba]

Přijde mi, že dvě jádra i 4GB RAM jsou dost málo. Já collaboru neprovozuji. Ale očekávám, že bude na výkon náročná.

Pustil bych si "top" a sledoval co se snaží běžet a kolik paměti to chce při požadavku na editaci dokumentu.

Já provozuji nextcloud a GitLab v kontejneru na Xeon(R) E3-1220L V2 a málo RAM (3 jádra, 8GB) a je to líné.

[darebacik]

Možná bych to viděl na nějaký problém s DNS, kdy se to zkouší doptat na reverzní záznam a timeoutuje to. A jako další bych viděl problém v tom, že se automaticky nespouští cron skript a tak si to jako fallback spouští při requestech po nějaké době a trvá to, než se cron odbaví.

Background jobs su nastavene defaultne na ajax, nie na cron (pokial myslis toto).

Přijde mi, že dvě jádra i 4GB RAM jsou dost málo. Já collaboru neprovozuji. Ale očekávám, že bude na výkon náročná.

Pustil bych si "top" a sledoval co se snaží běžet a kolik paměti to chce při požadavku na editaci dokumentu.

Já provozuji nextcloud a GitLab v kontejneru na Xeon(R) E3-1220L V2 a málo RAM (3 jádra, 8GB) a je to líné.

Nemyslim si, ze 4GB RAM a 2 cores je malo, ono sa to flaka. CPU niekde na 0.5-1% a RAM 4%.
Collabora je v inom LXC, cize nextcloud sa len pripaja na collabora server.

Inak ako som spomenul, problem je vzdy len s prvym spustenim. Potom sa dokumenty otvaraju do sekundy.

[Quba]

Možná bych to viděl na nějaký problém s DNS, kdy se to zkouší doptat na reverzní záznam a timeoutuje to. A jako další bych viděl problém v tom, že se automaticky nespouští cron skript a tak si to jako fallback spouští při requestech po nějaké době a trvá to, než se cron odbaví.

Background jobs su nastavene defaultne na ajax, nie na cron (pokial myslis toto).

Zkusil bych nastavit cron namísto ajax. Při prvním přihlášení totiž nextcloud zřejmě řeší všechny "resty" od posledního přihlášení.

Do logů apache, nextcloud, php, redis, ... jsi se díval?

[jfila]

Stejný problém jsem řešil také, provozoval jsem to na Turrisu, takže jsem považoval za slabé místo zde. Tak mě napadlo to otestovat na notebooku, i7, 16 GB RAM a přihlašování bylo stejně dlouhé. CPU se nudil, RAM také nic moc, na HDD toho moc nebylo, ale i tak je to SSD. DNS je zajímavý podmět.

[Lukinno]

Zdravím,

Zkoušel jste tento návod? https://docs.nextcloud.com/server/latest/admin_manual/installation/server_tuning.html

Pokud se stránka poprvé načítá pomaleji, a nextcloud jako takový vytěžuje málo CPU/RAM, zaměřil bych se na část "PHP-FPM Tuning" v odkazu výše.

Zvýšit rychlost načítání můžete samozřejmě i přechodem na TLSv1.3, HTTP/2 a také zapnutím cachování (vše v odkazu).

[jfila]

S tím jsem si také hrál, ale bez nějakého znatelného výsledku. Ale třeba se doba změnila a rady, které jsem na uvedené stránce četl před rokem a půl už úplně neplatí a všechno si to nepamatuji.

[Vantomas]

Možná bych to viděl na nějaký problém s DNS, kdy se to zkouší doptat na reverzní záznam a timeoutuje to. A jako další bych viděl problém v tom, že se automaticky nespouští cron skript a tak si to jako fallback spouští při requestech po nějaké době a trvá to, než se cron odbaví.

Background jobs su nastavene defaultne na ajax, nie na cron (pokial myslis toto).

To je právě špatně. AJAX znamená, že když přijde uživatel, tak si to spolu s jeho požadavkem začne odbavovat úkoly, které to dělá samo v pozadí a nejspíš můžou být operace, které jsou blokující a dokud se nevyřeší, tak uživatel čeká.

Správně má být nastaveno cronem, že se Nextcloud skript spouští třeba každých 5 minut a řeší si to ty background tasky samo, bez vlivu na to, zda uživatel posílá nebo neposílá requesty.

[madmucho]

Zdravím,
podle chování bych si typnul že se buď vůbec nepoužívá FPM a nebo je v modu on demand kdy neběží worker dokud se po něm nic nechce, a jak se po něm nic nechce x sec tak se worker vypne. Pokud je FPM tak bych ho nastavil na dynamic.
A určitě mít zapnutou nějakou keš, memcache asi nejjednodužší, a respektovat doporučení na opcache v php.ini

v php.ini pro opcache

Kód: [Vybrat]

opcache.enable=1
opcache.enable_cli=1
opcache.memory_consumption=140
opcache.interned_strings_buffer=25
opcache.max_accelerated_files=10000
opcache.fast_shutdown=1
opcache.revalidate_freq=1

memcace na lokalu bežící nastavená v config.php

Kód: [Vybrat]

'memcache.local' => '\\OC\\Memcache\\Memcached',
  'memcache.distributed' => '\\OC\\Memcache\\Memcached',
  'memcached_servers' =>.
  array (
    0 =>.
    array (
      0 => '127.0.0.1',
      1 => 11211,
    ),
  ),