Fórum Root.cz
Hlavní témata => Server => Téma založeno: darebacik 03. 04. 2023, 21:12:48
-
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.
-
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.
-
A nečekate jenom na na probuzení disku?
-
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?
-
zkuste vymazat svoji IP z tabulky oc_bruteforce_attempts
-
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).
-
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í.
-
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é.
-
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.
-
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?
-
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.
-
Zdravím,
Zkoušel jste tento návod? https://docs.nextcloud.com/server/latest/admin_manual/installation/server_tuning.html (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).
-
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.
-
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.
-
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
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
'memcache.local' => '\\OC\\Memcache\\Memcached',
'memcache.distributed' => '\\OC\\Memcache\\Memcached',
'memcached_servers' =>.
array (
0 =>.
array (
0 => '127.0.0.1',
1 => 11211,
),
),
-
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.
Myslim si, ze na 90% to cron vyriesil (mam to nastavene teraz podla dokumentacie na kazdych 5 minut). Len to este overim, ked budem mimo lokalnu siet (nextcloud).
Dokumenty sa v collabora stale otvaraju pomaly (resp. prvy dokument sa otvara pomaly).
PHP-FPM mam
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
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
'memcache.local' => '\\OC\\Memcache\\Memcached',
'memcache.distributed' => '\\OC\\Memcache\\Memcached',
'memcached_servers' =>.
array (
0 =>.
array (
0 => '127.0.0.1',
1 => 11211,
),
),
Pouzivam php-fpm, len zatial som do toho nesahal.
-
Myslim si, ze na 90% to cron vyriesil (mam to nastavene teraz podla dokumentacie na kazdych 5 minut). Len to este overim, ked budem mimo lokalnu siet (nextcloud).
Dokumenty sa v collabora stale otvaraju pomaly (resp. prvy dokument sa otvara pomaly).
Collaboru neznám, tak nemám tušení, zda je to pomalé otevirání vlastnost nebo chyba. Pokud je to vlastnost, neudělámě s tím skoro nic, jen to třeba z 10 sekund půjde stáhnout na 5. A pokud je to chyba, vidím to na problém s DNS nebo s nedostupností do internetu uvnitř kontejneru. Nextcloud samotný si stahuje informace o aktualizacích sebe a balíčků a Collabora může dělat totéž. Pokud by z kontejneru nešlo jít ven nebo to mělo problém s DNS, mohlo by se to projevovat přesně takhle.
Diagnostikovat by to šlo relativně snadno, z kontejneru zkusit spustit ping na nějaká jména, která se málo používají a ještě nejsou nacachovaná, např. moje oblíbené: yahoo.com, atlas.cz
Když se ten příkaz spustí, musí to začít prakticky okamžitě vypisovat po 1 sekundě řádky s odpověďmi. Jak to mezi řádky trvá déle jak sekundu nebo trvá déle než to začne cokoliv vypisovat, tak je něco zle.
-
Ping z nextcloud kontajnera, uplne OK
PING yahoo.com (74.6.231.21) 56(84) bytes of data.
64 bytes from media-router-fp74.prod.media.vip.ne1.yahoo.com (74.6.231.21): icmp_seq=1 ttl=42 time=153 ms
64 bytes from media-router-fp74.prod.media.vip.ne1.yahoo.com (74.6.231.21): icmp_seq=2 ttl=42 time=153 ms
64 bytes from media-router-fp74.prod.media.vip.ne1.yahoo.com (74.6.231.21): icmp_seq=3 ttl=42 time=153 ms
64 bytes from media-router-fp74.prod.media.vip.ne1.yahoo.com (74.6.231.21): icmp_seq=4 ttl=42 time=153 ms
64 bytes from media-router-fp74.prod.media.vip.ne1.yahoo.com (74.6.231.21): icmp_seq=5 ttl=42 time=153 ms
64 bytes from media-router-fp74.prod.media.vip.ne1.yahoo.com (74.6.231.21): icmp_seq=6 ttl=42 time=153 ms
64 bytes from media-router-fp74.prod.media.vip.ne1.yahoo.com (74.6.231.21): icmp_seq=7 ttl=42 time=153 ms
64 bytes from media-router-fp74.prod.media.vip.ne1.yahoo.com (74.6.231.21): icmp_seq=8 ttl=42 time=153 ms
64 bytes from media-router-fp74.prod.media.vip.ne1.yahoo.com (74.6.231.21): icmp_seq=9 ttl=42 time=153 ms
ping z collabora kontajnera, uplne OK
PING yahoo.com (74.6.143.26) 56(84) bytes of data.
64 bytes from media-router-fp74.prod.media.vip.bf1.yahoo.com (74.6.143.26): icmp_seq=1 ttl=45 time=118 ms
64 bytes from media-router-fp74.prod.media.vip.bf1.yahoo.com (74.6.143.26): icmp_seq=2 ttl=45 time=118 ms
64 bytes from media-router-fp74.prod.media.vip.bf1.yahoo.com (74.6.143.26): icmp_seq=3 ttl=45 time=118 ms
64 bytes from media-router-fp74.prod.media.vip.bf1.yahoo.com (74.6.143.26): icmp_seq=4 ttl=45 time=118 ms
64 bytes from media-router-fp74.prod.media.vip.bf1.yahoo.com (74.6.143.26): icmp_seq=5 ttl=44 time=118 ms
64 bytes from media-router-fp74.prod.media.vip.bf1.yahoo.com (74.6.143.26): icmp_seq=6 ttl=45 time=118 ms
64 bytes from media-router-fp74.prod.media.vip.bf1.yahoo.com (74.6.143.26): icmp_seq=7 ttl=45 time=118 ms
64 bytes from media-router-fp74.prod.media.vip.bf1.yahoo.com (74.6.143.26): icmp_seq=8 ttl=45 time=118 ms
64 bytes from media-router-fp74.prod.media.vip.bf1.yahoo.com (74.6.143.26): icmp_seq=9 ttl=45 time=118 ms
Obidva kontajnery su na jednom fyzickom stroji. Neviem ci som spominal, ale vsetky webovky mam za reverznym proxy a config pre collabora som prebral z dokumentacie.
server {
listen 443 ssl;
server_name code.example.com;
ssl_certificate /etc/letsencrypt/live/code.example.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/code.example.com/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
location / {
proxy_pass http://10.10.10.2:9980;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
# static files
location ^~ /browser {
proxy_pass http://10.10.10.2:9980;
proxy_set_header Host $http_host;
}
# WOPI discovery URL
location ^~ /hosting/discovery {
proxy_pass http://10.10.10.2:9980;
proxy_set_header Host $http_host;
}
# Capabilities
location ^~ /hosting/capabilities {
proxy_pass http://10.10.10.2:9980;
proxy_set_header Host $http_host;
}
# main websocket
location ~ ^/cool/(.*)/ws$ {
proxy_pass http://10.10.10.2:9980;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
proxy_set_header Host $http_host;
proxy_read_timeout 36000s;
}
# download, presentation and image upload
location ~ ^/(c|l)ool {
proxy_pass http://10.10.10.2:9980;
proxy_set_header Host $http_host;
}
# Admin Console websocket
location ^~ /cool/adminws {
proxy_pass http://10.10.10.2:9980;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
proxy_set_header Host $http_host;
proxy_read_timeout 36000s;
}
}
server {
if ($host = code.example.com) {
return 301 https://$host$request_uri;
} # managed by Certbot
listen 80;
server_name code.example.com;
return 404; # managed by Certbot
}
-
Zatial som to nevyriesil, ale prisiel som na pricinu problemu. Na servery nextcloud mam povoleny UFW s portami pre http, https a ssh. Ak UFW disablujem, tak office dokumenty sa nacitaju okamzite. Ak UFW s portami 80, 443, a 22 enablujem, tak prvy dokument sa nacitava az po 6-8 sekundach a dalsie okamzite. vyzera to na problem s firewallom
Firewall by mal fungovat tak, ze bud to blokuje, alebo neblokuje. Teoreticky to neblokuje, ale nejak to tomu vadi. Nerozumiem tomu.
-
Nepokúša sa to komunikovať aj na iných portoch ako 80 a 443? A keď sa mu to nepodarí, tak sa vráti k 80, 443? Možno ten websocket?
-
To se mi nezdá, wireshark?
-
Zatial som to nevyriesil, ale prisiel som na pricinu problemu. Na servery nextcloud mam povoleny UFW s portami pre http, https a ssh. Ak UFW disablujem, tak office dokumenty sa nacitaju okamzite. Ak UFW s portami 80, 443, a 22 enablujem, tak prvy dokument sa nacitava az po 6-8 sekundach a dalsie okamzite. vyzera to na problem s firewallom
Firewall by mal fungovat tak, ze bud to blokuje, alebo neblokuje. Teoreticky to neblokuje, ale nejak to tomu vadi. Nerozumiem tomu.
V tom případě si zapnout logování zahozených paketů a pak z toho zjišťovat kam to zkouší komunikovat. https://linuxhint.com/check-my-ufw-log/ (https://linuxhint.com/check-my-ufw-log/)
sudo ufw logging on
cat /var/log/ufw.log
-
Ospravedlnujem sa, ale UFW nerobi problemy (bol to plany poplach).