Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Wordpress site traag na verhuizing
1 view
Skip to first unread message
Paul van der Vlis
Jan 30, 2024, 10:24:14 AM1/30/24
to
Hoi,
Ik heb een Wordpress site verhuist van een gespecialiseerde provider
naar mijn webserver. Eerst voor test, dus ik kan hem alleen zien via een
aangepast hosts-bestand.
Maar hij is nu erg traag, het laden van de eerste pagina duurt soms meer
dan 25 seconden... Mijn webserver is behoorlijk snel omdat alles op NVMe
staat, dus er klopt ergens iets niet.
Ik doe dit wel vaker, en dat gaat altijd wel goed. Ik kopieer de
bestanden, pas wat dingen aan (zoals de naam van de database). Verder
dump ik de database, pas daar de paden aan, fix de serialisatie, en lees
hem weer in.
Het viel me hier op dat er een map "wp-content/mu-plugins" was die niet
te kopieren was (een symlink naar elders). Dit zijn een soort verplichte
plugins:
https://developer.wordpress.org/advanced-administration/plugins/mu-plugins/
Mijn ervaring is dat als je een plugin-mapje verwijderd de plugin gewoon
weg is. Dus dan zou er niets aan de hand zijn.
Verder was er een rare .htaccess van 1 byte groot, daar moest ik wat
anders inzetten anders werkten de paden niet. Wellicht stond er iets in
wat ik niet kon lezen via SFTP.
Ik heb ingelogged, maar ik zie in het beheer-interface geen
foutmeldingen o.i.d.
Heeft hier iemand nog een idee wat er kan zijn? Hij doet het dus wel
correct, maar hij laadt heel erg traag...
Groet,
Paul
--
Paul van der Vlis Linux systeembeheer Groningen
https://vandervlis.nl
Ik heb een Wordpress site verhuist van een gespecialiseerde provider
naar mijn webserver. Eerst voor test, dus ik kan hem alleen zien via een
aangepast hosts-bestand.
Maar hij is nu erg traag, het laden van de eerste pagina duurt soms meer
dan 25 seconden... Mijn webserver is behoorlijk snel omdat alles op NVMe
staat, dus er klopt ergens iets niet.
Ik doe dit wel vaker, en dat gaat altijd wel goed. Ik kopieer de
bestanden, pas wat dingen aan (zoals de naam van de database). Verder
dump ik de database, pas daar de paden aan, fix de serialisatie, en lees
hem weer in.
Het viel me hier op dat er een map "wp-content/mu-plugins" was die niet
te kopieren was (een symlink naar elders). Dit zijn een soort verplichte
plugins:
https://developer.wordpress.org/advanced-administration/plugins/mu-plugins/
Mijn ervaring is dat als je een plugin-mapje verwijderd de plugin gewoon
weg is. Dus dan zou er niets aan de hand zijn.
Verder was er een rare .htaccess van 1 byte groot, daar moest ik wat
anders inzetten anders werkten de paden niet. Wellicht stond er iets in
wat ik niet kon lezen via SFTP.
Ik heb ingelogged, maar ik zie in het beheer-interface geen
foutmeldingen o.i.d.
Heeft hier iemand nog een idee wat er kan zijn? Hij doet het dus wel
correct, maar hij laadt heel erg traag...
Groet,
Paul
--
Paul van der Vlis Linux systeembeheer Groningen
https://vandervlis.nl
Jaap
Jan 30, 2024, 3:26:05 PM1/30/24
to
Op 30-01-2024 om 16:24 schreef Paul van der Vlis:
Een bijzonder probleem. Als ik het zou hebben zou ik eerst naar het
.htaccess kijken, kan je daar niet iets 'echts' maar onschuldigs in
zetten? Zit er niet een byte order mark voor die problemen oplevert?
Werkt de database snel als je er direct zelf een query naar toe stuurt?
Is er nog een process wat veel tijd neemt tijdens een request?
Ooit heb ik op mijn werk het verhaal gehoord van een leverancier die bij
elk request even naar huis belde. Maar ja, onze firewall stond dat niet
toe dus werd de applicatie zeldzaam traag. Heb je een firewall?
Heb je alle Apache plugins voor PHP geladen? Ik heb wel eens een Perl
applicatie gehad die zeldzaam traag was omdat een plugin ontbrak.
Veel succes!
Jaap
.htaccess kijken, kan je daar niet iets 'echts' maar onschuldigs in
zetten? Zit er niet een byte order mark voor die problemen oplevert?
Werkt de database snel als je er direct zelf een query naar toe stuurt?
Is er nog een process wat veel tijd neemt tijdens een request?
Ooit heb ik op mijn werk het verhaal gehoord van een leverancier die bij
elk request even naar huis belde. Maar ja, onze firewall stond dat niet
toe dus werd de applicatie zeldzaam traag. Heb je een firewall?
Heb je alle Apache plugins voor PHP geladen? Ik heb wel eens een Perl
applicatie gehad die zeldzaam traag was omdat een plugin ontbrak.
Veel succes!
Jaap
Richard Lucassen
Jan 30, 2024, 5:00:10 PM1/30/24
to
On Tue, 30 Jan 2024 16:24:12 +0100
Paul van der Vlis <pa...@vandervlis.nl> wrote:
> Heeft hier iemand nog een idee wat er kan zijn? Hij doet het dus wel
> correct, maar hij laadt heel erg traag...
Zou het een resolving probleem kunnen zijn? Dat-ie naar z'n eigen
Paul van der Vlis <pa...@vandervlis.nl> wrote:
> Heeft hier iemand nog een idee wat er kan zijn? Hij doet het dus wel
> correct, maar hij laadt heel erg traag...
hostname zoekt die niet bijvoorbeeld in /etc/hosts staat?
--
Richard Lucassen <mailin...@lucassen.org>
Paul van der Vlis
Jan 31, 2024, 5:22:11 AM1/31/24
to
Op 30-01-2024 om 21:26 schreef Jaap:
Dat heb ik gedaan, ik heb er neergezet wat er default in staat.
Maar ik weet dus niet wat er in de originele stond.
Voordat ik dit deed deed de "voorkant" het wel, maar liep elke URL in
het niets.
Ik zat me nog te bedenken dat ik het wellicht niet zie via SFTP, maar
dat Apache het wel moet kunnen lezen. Via een applicatie als phpshell
zou ik het dus wel moeten kunnen lezen. Maar wellicht stuit dat weer op
andere problemen.
> Zit er niet een byte order mark voor die problemen oplevert?
Dat ken ik niet goed.. Wat doet zoiets?
> Werkt de database snel als je er direct zelf een query naar toe stuurt?
Er draaien vele websites op die server, deze draaien goed & snel.
Ik zat nog te denken aan te loggen op slow querys, maar heb daar niet
zoveel verstand van...
Dit wou ik eens bestuderen en proberen, aanwijzingen zijn welkom:
https://mariadb.com/kb/en/slow-query-log-overview/
Het valt me wel op dat de voorpagina veel trager is dan de andere pagina's.
> Is er nog een process wat veel tijd neemt tijdens een request?
Hoe kom ik daar achter? Ik zie niets hierover in de logs.
Wat me daar wel opvalt is dat ik na elk request "nocache=1" zie.
> Ooit heb ik op mijn werk het verhaal gehoord van een leverancier die bij
> elk request even naar huis belde. Maar ja, onze firewall stond dat niet
> toe dus werd de applicatie zeldzaam traag. Heb je een firewall?
Uiteraard, maar die doet niet veel bijzonders. Uitgaand verkeer en
antwoorden daarop zijn gewoon toegestaan.
> Heb je alle Apache plugins voor PHP geladen?
Dat zijn er nogal wat... Vast niet alle.
> Ik heb wel eens een Perl
> applicatie gehad die zeldzaam traag was omdat een plugin ontbrak.
Ik zou toch verwachten dat in de logs te kunnen zien.
Maar ik weet dus niet wat er in de originele stond.
Voordat ik dit deed deed de "voorkant" het wel, maar liep elke URL in
het niets.
Ik zat me nog te bedenken dat ik het wellicht niet zie via SFTP, maar
dat Apache het wel moet kunnen lezen. Via een applicatie als phpshell
zou ik het dus wel moeten kunnen lezen. Maar wellicht stuit dat weer op
andere problemen.
> Zit er niet een byte order mark voor die problemen oplevert?
> Werkt de database snel als je er direct zelf een query naar toe stuurt?
Ik zat nog te denken aan te loggen op slow querys, maar heb daar niet
zoveel verstand van...
Dit wou ik eens bestuderen en proberen, aanwijzingen zijn welkom:
https://mariadb.com/kb/en/slow-query-log-overview/
Het valt me wel op dat de voorpagina veel trager is dan de andere pagina's.
> Is er nog een process wat veel tijd neemt tijdens een request?
Wat me daar wel opvalt is dat ik na elk request "nocache=1" zie.
> Ooit heb ik op mijn werk het verhaal gehoord van een leverancier die bij
> elk request even naar huis belde. Maar ja, onze firewall stond dat niet
> toe dus werd de applicatie zeldzaam traag. Heb je een firewall?
antwoorden daarop zijn gewoon toegestaan.
> Heb je alle Apache plugins voor PHP geladen?
> Ik heb wel eens een Perl
> applicatie gehad die zeldzaam traag was omdat een plugin ontbrak.
Paul van der Vlis
Jan 31, 2024, 5:33:49 AM1/31/24
to
Op 30-01-2024 om 23:00 schreef Richard Lucassen:
Ik gebruik mijn eigen nameservers.
> Dat-ie naar z'n eigen
> hostname zoekt die niet bijvoorbeeld in /etc/hosts staat?
Als hij via DNS naar zijn domeinnaam zoekt krijg hij inderdaad een heel
ander IP. Maar dat is normaal geen probleem.
Ik heb voor de grap even de domeinnaam in /etc/hosts gezet met het IP en
IPv6 van die machine, maar dat maakt geen verschil.
De hostname staat wel correct in /etc/hosts. Het is een server die al
jaren correct draait met vele sites, ook veel Wordpress.
> On Tue, 30 Jan 2024 16:24:12 +0100
> Paul van der Vlis <pa...@vandervlis.nl> wrote:
>
>> Heeft hier iemand nog een idee wat er kan zijn? Hij doet het dus wel
>> correct, maar hij laadt heel erg traag...
> Zou het een resolving probleem kunnen zijn?
Zoiets zou kunnen, maar hoe kom ik er achter?
> Paul van der Vlis <pa...@vandervlis.nl> wrote:
>
>> Heeft hier iemand nog een idee wat er kan zijn? Hij doet het dus wel
>> correct, maar hij laadt heel erg traag...
> Zou het een resolving probleem kunnen zijn?
Ik gebruik mijn eigen nameservers.
> Dat-ie naar z'n eigen
> hostname zoekt die niet bijvoorbeeld in /etc/hosts staat?
ander IP. Maar dat is normaal geen probleem.
Ik heb voor de grap even de domeinnaam in /etc/hosts gezet met het IP en
IPv6 van die machine, maar dat maakt geen verschil.
De hostname staat wel correct in /etc/hosts. Het is een server die al
jaren correct draait met vele sites, ook veel Wordpress.
Richard Lucassen
Jan 31, 2024, 5:43:34 AM1/31/24
to
On Wed, 31 Jan 2024 11:33:46 +0100
Paul van der Vlis <pa...@vandervlis.nl> wrote:
> > Dat-ie naar z'n eigen
> > hostname zoekt die niet bijvoorbeeld in /etc/hosts staat?
>
> Als hij via DNS naar zijn domeinnaam zoekt krijg hij inderdaad een
> heel ander IP. Maar dat is normaal geen probleem.
>
> Ik heb voor de grap even de domeinnaam in /etc/hosts gezet met het IP
> en IPv6 van die machine, maar dat maakt geen verschil.
>
> De hostname staat wel correct in /etc/hosts. Het is een server die al
> jaren correct draait met vele sites, ook veel Wordpress.
Ik bedoelde eerder dat-ie zoekt naar de hostname van de server waar het
Paul van der Vlis <pa...@vandervlis.nl> wrote:
> > Dat-ie naar z'n eigen
> > hostname zoekt die niet bijvoorbeeld in /etc/hosts staat?
>
> Als hij via DNS naar zijn domeinnaam zoekt krijg hij inderdaad een
> heel ander IP. Maar dat is normaal geen probleem.
>
> Ik heb voor de grap even de domeinnaam in /etc/hosts gezet met het IP
> en IPv6 van die machine, maar dat maakt geen verschil.
>
> De hostname staat wel correct in /etc/hosts. Het is een server die al
> jaren correct draait met vele sites, ook veel Wordpress.
eerst op draaide. Je had het spul toch verhuisd? Misschien zoekt-ie wel
een niet zo belangrijke lib die op de oude server wel stond maar op de
nieuwe niet?
Apache in debug mode draaien een optie?
--
Richard Lucassen <mailin...@lucassen.org>
Paul van der Vlis
Jan 31, 2024, 6:21:06 AM1/31/24
to
Op 31-01-2024 om 11:22 schreef Paul van der Vlis:
Ik heb in /etc/mysql/mariadb.conf.d/50-server.cnf deze regels gezet:
slow_query_log = 1
slow_query_log_file = /var/log/mysql/mariadb-slow.log
long_query_time = 10
log_slow_verbosity = query_plan,explain
Er verschijnt een /var/log/mysql/mariadb-slow.log, maar ik zie hierin
niets als ik de pagina reload.
Groet,
Paul
slow_query_log = 1
slow_query_log_file = /var/log/mysql/mariadb-slow.log
long_query_time = 10
log_slow_verbosity = query_plan,explain
Er verschijnt een /var/log/mysql/mariadb-slow.log, maar ik zie hierin
niets als ik de pagina reload.
Groet,
Paul
Paul van der Vlis
Jan 31, 2024, 7:30:24 AM1/31/24
to
Op 31-01-2024 om 11:43 schreef Richard Lucassen:
> Misschien zoekt-ie wel
> een niet zo belangrijke lib die op de oude server wel stond maar op de
> nieuwe niet?
>
> Apache in debug mode draaien een optie?
Dat doe ik nu, en dat blijkt zelfs per vhost geregeld te kunnen worden ;-)
Het zou een SSL probleem kunnen zijn. Uiteraard doet de SSL het niet
correct want dit is een test-verhuizing, daarom gebruik ik een verkeerd
certificaat en heb ik een uitzondering in Firefox toegevoegd. Normaal is
dat geen probleem, misschien hier wel door de HSTS policy?
Of heeft dit iets met mod_deflate te maken?
----------
[Wed Jan 31 12:58:31.245619 2024] [ssl:debug] [pid 826854]
ssl_engine_io.c(1147): [client 188.213.90.187:59426] AH02001: Connection
closed to child 5 with standa
rd shutdown (server mydomain.nl:443)
[Wed Jan 31 13:02:33.859558 2024] [ssl:debug] [pid 828018]
ssl_engine_kernel.c(415): [client 188.213.90.187:36442] AH02034: Initial
(No.1) HTTPS request received for child 10 (server mydomain.nl:443)
[Wed Jan 31 13:02:33.861954 2024] [authz_core:debug] [pid 828018]
mod_authz_core.c(815): [client 188.213.90.187:36442] AH01626:
authorization result of Require all granted: granted
[Wed Jan 31 13:02:33.861999 2024] [authz_core:debug] [pid 828018]
mod_authz_core.c(815): [client 188.213.90.187:36442] AH01626:
authorization result of <RequireAny>: granted
[Wed Jan 31 13:02:33.862647 2024] [authz_core:debug] [pid 828018]
mod_authz_core.c(815): [client 188.213.90.187:36442] AH01626:
authorization result of Require all granted: granted
[Wed Jan 31 13:02:33.862681 2024] [authz_core:debug] [pid 828018]
mod_authz_core.c(815): [client 188.213.90.187:36442] AH01626:
authorization result of <RequireAny>: granted
<hier duurt het lang, ik heb niets verwijderd>
[Wed Jan 31 13:03:00.576336 2024] [deflate:debug] [pid 828018]
mod_deflate.c(869): [client 188.213.90.187:36442] AH01384: Zlib:
Compressed 609772 to 86828 : URL /index.php
[Wed Jan 31 13:03:00.776425 2024] [ssl:debug] [pid 828018]
ssl_engine_kernel.c(415): [client 188.213.90.187:36442] AH02034:
Subsequent (No.2) HTTPS request received for child 10 (server
mydomain.nl:443), referer: https://mydomain.nl/
----------
Ik zag nog deze instelling:
SSLCompression off
> On Wed, 31 Jan 2024 11:33:46 +0100
> Paul van der Vlis <pa...@vandervlis.nl> wrote:
>
>>> Dat-ie naar z'n eigen
>>> hostname zoekt die niet bijvoorbeeld in /etc/hosts staat?
>>
>> Als hij via DNS naar zijn domeinnaam zoekt krijg hij inderdaad een
>> heel ander IP. Maar dat is normaal geen probleem.
>>
>> Ik heb voor de grap even de domeinnaam in /etc/hosts gezet met het IP
>> en IPv6 van die machine, maar dat maakt geen verschil.
>>
>> De hostname staat wel correct in /etc/hosts. Het is een server die al
>> jaren correct draait met vele sites, ook veel Wordpress.
>
> Ik bedoelde eerder dat-ie zoekt naar de hostname van de server waar het
> eerst op draaide. Je had het spul toch verhuisd?
Inderdaad.
> Paul van der Vlis <pa...@vandervlis.nl> wrote:
>
>>> Dat-ie naar z'n eigen
>>> hostname zoekt die niet bijvoorbeeld in /etc/hosts staat?
>>
>> Als hij via DNS naar zijn domeinnaam zoekt krijg hij inderdaad een
>> heel ander IP. Maar dat is normaal geen probleem.
>>
>> Ik heb voor de grap even de domeinnaam in /etc/hosts gezet met het IP
>> en IPv6 van die machine, maar dat maakt geen verschil.
>>
>> De hostname staat wel correct in /etc/hosts. Het is een server die al
>> jaren correct draait met vele sites, ook veel Wordpress.
>
> Ik bedoelde eerder dat-ie zoekt naar de hostname van de server waar het
> eerst op draaide. Je had het spul toch verhuisd?
> Misschien zoekt-ie wel
> een niet zo belangrijke lib die op de oude server wel stond maar op de
> nieuwe niet?
>
> Apache in debug mode draaien een optie?
Het zou een SSL probleem kunnen zijn. Uiteraard doet de SSL het niet
correct want dit is een test-verhuizing, daarom gebruik ik een verkeerd
certificaat en heb ik een uitzondering in Firefox toegevoegd. Normaal is
dat geen probleem, misschien hier wel door de HSTS policy?
Of heeft dit iets met mod_deflate te maken?
----------
[Wed Jan 31 12:58:31.245619 2024] [ssl:debug] [pid 826854]
ssl_engine_io.c(1147): [client 188.213.90.187:59426] AH02001: Connection
closed to child 5 with standa
rd shutdown (server mydomain.nl:443)
[Wed Jan 31 13:02:33.859558 2024] [ssl:debug] [pid 828018]
ssl_engine_kernel.c(415): [client 188.213.90.187:36442] AH02034: Initial
(No.1) HTTPS request received for child 10 (server mydomain.nl:443)
[Wed Jan 31 13:02:33.861954 2024] [authz_core:debug] [pid 828018]
mod_authz_core.c(815): [client 188.213.90.187:36442] AH01626:
authorization result of Require all granted: granted
[Wed Jan 31 13:02:33.861999 2024] [authz_core:debug] [pid 828018]
mod_authz_core.c(815): [client 188.213.90.187:36442] AH01626:
authorization result of <RequireAny>: granted
[Wed Jan 31 13:02:33.862647 2024] [authz_core:debug] [pid 828018]
mod_authz_core.c(815): [client 188.213.90.187:36442] AH01626:
authorization result of Require all granted: granted
[Wed Jan 31 13:02:33.862681 2024] [authz_core:debug] [pid 828018]
mod_authz_core.c(815): [client 188.213.90.187:36442] AH01626:
authorization result of <RequireAny>: granted
<hier duurt het lang, ik heb niets verwijderd>
[Wed Jan 31 13:03:00.576336 2024] [deflate:debug] [pid 828018]
mod_deflate.c(869): [client 188.213.90.187:36442] AH01384: Zlib:
Compressed 609772 to 86828 : URL /index.php
[Wed Jan 31 13:03:00.776425 2024] [ssl:debug] [pid 828018]
ssl_engine_kernel.c(415): [client 188.213.90.187:36442] AH02034:
Subsequent (No.2) HTTPS request received for child 10 (server
mydomain.nl:443), referer: https://mydomain.nl/
----------
Ik zag nog deze instelling:
SSLCompression off
Paul van der Vlis
Jan 31, 2024, 8:50:25 AM1/31/24
to
Op 31-01-2024 om 13:30 schreef Paul van der Vlis:
<knip>
Ik heb de compressie uitgezet met "SetEnv no-gzip 1" in de vhost
configuratie. Ik zie nu niets meer in de logs hierover.
Verder SSL uitgezet door in de SQL "https:" te vervangen door "http:",
ik zie nu niets meer over SSL in de logs.
Het lijkt met "mod_authz" te maken te hebben, dat is het enige wat ik
nog zie in error_log:
--------
[Wed Jan 31 14:15:26.166270 2024] [authz_core:debug] [pid 841348]
mod_authz_core.c(815): [client 188.213.90.187:34926] AH01626:
mod_authz_core.c(815): [client 188.213.90.187:34926] AH01626:
mod_authz_core.c(815): [client 188.213.90.187:34926] AH01626:
mod_authz_core.c(815): [client 188.213.90.187:34926] AH01626:
[Wed Jan 31 14:15:51.018340 2024] [authz_core:debug] [pid 841348]
mod_authz_core.c(815): [client 188.213.90.187:34926] AH01626:
authorization result of Require all granted: granted, referer:
http://mydomain.nl/
[Wed Jan 31 14:15:51.018408 2024] [authz_core:debug] [pid 841348]
mod_authz_core.c(815): [client 188.213.90.187:34926] AH01626:
authorization result of <RequireAny>: granted, referer: http://mydomain.nl/
[Wed Jan 31 14:15:51.035364 2024] [authz_core:debug] [pid 841414]
mod_authz_core.c(815): [client 188.213.90.187:37944] AH01626:
authorization result of Require all granted: granted, referer:
http://mydomain.nl/
--------
In mijn vhost-config staat gewoon dit:
<Directory /home/edagenda/www>
AllowOverride all
Require all granted
</Directory>
Groet,
Paul
--
Paul van der Vlis Linux systeembeheer Groningen
https://vandervlis.nl/
<knip>
Ik heb de compressie uitgezet met "SetEnv no-gzip 1" in de vhost
configuratie. Ik zie nu niets meer in de logs hierover.
Verder SSL uitgezet door in de SQL "https:" te vervangen door "http:",
ik zie nu niets meer over SSL in de logs.
Het lijkt met "mod_authz" te maken te hebben, dat is het enige wat ik
nog zie in error_log:
--------
[Wed Jan 31 14:15:26.166270 2024] [authz_core:debug] [pid 841348]
mod_authz_core.c(815): [client 188.213.90.187:34926] AH01626:
authorization result of Require all granted: granted
[Wed Jan 31 14:15:26.166382 2024] [authz_core:debug] [pid 841348]
mod_authz_core.c(815): [client 188.213.90.187:34926] AH01626:
authorization result of <RequireAny>: granted
[Wed Jan 31 14:15:26.166860 2024] [authz_core:debug] [pid 841348]
mod_authz_core.c(815): [client 188.213.90.187:34926] AH01626:
authorization result of Require all granted: granted
[Wed Jan 31 14:15:26.166885 2024] [authz_core:debug] [pid 841348]
mod_authz_core.c(815): [client 188.213.90.187:34926] AH01626:
authorization result of <RequireAny>: granted
<hier zit de vertraging, niets verwijderd>
[Wed Jan 31 14:15:51.018340 2024] [authz_core:debug] [pid 841348]
mod_authz_core.c(815): [client 188.213.90.187:34926] AH01626:
authorization result of Require all granted: granted, referer:
http://mydomain.nl/
[Wed Jan 31 14:15:51.018408 2024] [authz_core:debug] [pid 841348]
mod_authz_core.c(815): [client 188.213.90.187:34926] AH01626:
authorization result of <RequireAny>: granted, referer: http://mydomain.nl/
[Wed Jan 31 14:15:51.035364 2024] [authz_core:debug] [pid 841414]
mod_authz_core.c(815): [client 188.213.90.187:37944] AH01626:
authorization result of Require all granted: granted, referer:
http://mydomain.nl/
--------
In mijn vhost-config staat gewoon dit:
<Directory /home/edagenda/www>
AllowOverride all
Require all granted
</Directory>
Groet,
Paul
--
Paul van der Vlis Linux systeembeheer Groningen
Paul van der Vlis
Jan 31, 2024, 9:31:12 AM1/31/24
to
Hallo allen,
Wat me nog opvalt is dat de vertraging optreed als er voor het eerst een
"referer" is:
> mod_authz_core.c(815): [client 188.213.90.187:34926] AH01626:
> authorization result of <RequireAny>: granted
>
> <hier zit de vertraging, niets verwijderd>
>
> [Wed Jan 31 14:15:51.018340 2024] [authz_core:debug] [pid 841348]
> mod_authz_core.c(815): [client 188.213.90.187:34926] AH01626:
> authorization result of Require all granted: granted, referer:
> http://mydomain.nl/
> [Wed Jan 31 14:15:51.018408 2024] [authz_core:debug] [pid 841348]
Wat me nog opvalt is dat de vertraging optreed als er voor het eerst een
"referer" is:
> mod_authz_core.c(815): [client 188.213.90.187:34926] AH01626:
> authorization result of <RequireAny>: granted
>
> <hier zit de vertraging, niets verwijderd>
>
> [Wed Jan 31 14:15:51.018340 2024] [authz_core:debug] [pid 841348]
> mod_authz_core.c(815): [client 188.213.90.187:34926] AH01626:
> authorization result of Require all granted: granted, referer:
> http://mydomain.nl/
> [Wed Jan 31 14:15:51.018408 2024] [authz_core:debug] [pid 841348]
Paul van der Vlis
Jan 31, 2024, 11:16:57 AM1/31/24
to
Op 31-01-2024 om 15:31 schreef Paul van der Vlis:
SSL-certificaat wat nu goed werkt. Maar hij is nog steeds net zo traag.
Opvallend is dat de voorpagina een stuk trager is dan andere pagina's.
De voorpagina heeft echt wel een vertraging ruim boven de 20 seconden.
Andere pagina's laten je ongeveer 10 seconden wachten.
Iemand een idee?
> Hallo allen,
>
> Wat me nog opvalt is dat de vertraging optreed als er voor het eerst een
> "referer" is:
>
> > mod_authz_core.c(815): [client 188.213.90.187:34926] AH01626:
> > authorization result of <RequireAny>: granted
> >
> > <hier zit de vertraging, niets verwijderd>
> >
> > [Wed Jan 31 14:15:51.018340 2024] [authz_core:debug] [pid 841348]
> > mod_authz_core.c(815): [client 188.213.90.187:34926] AH01626:
> > authorization result of Require all granted: granted, referer:
> > http://mydomain.nl/
> > [Wed Jan 31 14:15:51.018408 2024] [authz_core:debug] [pid 841348]
Ik heb hem ook nog overgezet naar een andere domeinnaam, compleet met
>
> Wat me nog opvalt is dat de vertraging optreed als er voor het eerst een
> "referer" is:
>
> > mod_authz_core.c(815): [client 188.213.90.187:34926] AH01626:
> > authorization result of <RequireAny>: granted
> >
> > <hier zit de vertraging, niets verwijderd>
> >
> > [Wed Jan 31 14:15:51.018340 2024] [authz_core:debug] [pid 841348]
> > mod_authz_core.c(815): [client 188.213.90.187:34926] AH01626:
> > authorization result of Require all granted: granted, referer:
> > http://mydomain.nl/
> > [Wed Jan 31 14:15:51.018408 2024] [authz_core:debug] [pid 841348]
SSL-certificaat wat nu goed werkt. Maar hij is nog steeds net zo traag.
Opvallend is dat de voorpagina een stuk trager is dan andere pagina's.
De voorpagina heeft echt wel een vertraging ruim boven de 20 seconden.
Andere pagina's laten je ongeveer 10 seconden wachten.
Iemand een idee?
Richard Lucassen
Feb 1, 2024, 12:35:53 PM2/1/24
to
On Wed, 31 Jan 2024 17:16:53 +0100
log van je DNS vanaf die host? Staat die server soms in een DMZ en wil
hij bijvoorbeeld een CRL ophalen o.i.d. wat-ie niet mag van de firewall?
Wil hij misschien ipv6 gebruiken en dat mag/kan ergens in het
path niet?
Het zijn lastige dingen in ieder geval.
--
Richard Lucassen <mailin...@lucassen.org>
> Ik heb hem ook nog overgezet naar een andere domeinnaam, compleet met
> SSL-certificaat wat nu goed werkt. Maar hij is nog steeds net zo
> traag.
>
> Opvallend is dat de voorpagina een stuk trager is dan andere
> pagina's. De voorpagina heeft echt wel een vertraging ruim boven de
> 20 seconden. Andere pagina's laten je ongeveer 10 seconden wachten.
>
> Iemand een idee?
20 sec riekt wel erg naar wachten op een antwoord van iets, Wat zegt de
> SSL-certificaat wat nu goed werkt. Maar hij is nog steeds net zo
> traag.
>
> Opvallend is dat de voorpagina een stuk trager is dan andere
> pagina's. De voorpagina heeft echt wel een vertraging ruim boven de
> 20 seconden. Andere pagina's laten je ongeveer 10 seconden wachten.
>
> Iemand een idee?
log van je DNS vanaf die host? Staat die server soms in een DMZ en wil
hij bijvoorbeeld een CRL ophalen o.i.d. wat-ie niet mag van de firewall?
Wil hij misschien ipv6 gebruiken en dat mag/kan ergens in het
path niet?
Het zijn lastige dingen in ieder geval.
--
Richard Lucassen <mailin...@lucassen.org>
Paul van der Vlis
Feb 1, 2024, 6:53:20 PM2/1/24
to
Op 01-02-2024 om 18:35 schreef Richard Lucassen:
Ik heb in de logs van mijn bind9 server gekeken, maar die logt zoiets
niet. Misschien kan hij ook meer verbose loggen.
Of door het netwerkverkeer te monitoren? (niet mijn sterke kant...)
> Staat die server soms in een DMZ en wil
> hij bijvoorbeeld een CRL ophalen o.i.d. wat-ie niet mag van de firewall?
Alles staat in het datacenter.
Het lijkt geen SSL probleem. Ik heb hem ook zonder SSL gedraaid en toen
was hij net zo traag.
Op diezelfde machine draai ik ook allerlei andere sites en die doen het
prima. Het is mijn shared hosting server.
https://vandervlis.nl draait er ook op, en ook vele Wordpress sites.
> Wil hij misschien ipv6 gebruiken en dat mag/kan ergens in het
> path niet?
IPv6 doet het prima...
> Het zijn lastige dingen in ieder geval.
Ik log de "slow queries" boven 1 seconde. Ik zie een query van ongeveer
2 seconden bij een reload, dat lijkt me toch niet echt alarmerend.
Ik weet het ook even niet.
> On Wed, 31 Jan 2024 17:16:53 +0100
> Paul van der Vlis <pa...@vandervlis.nl> wrote:
>
>> Ik heb hem ook nog overgezet naar een andere domeinnaam, compleet met
>> SSL-certificaat wat nu goed werkt. Maar hij is nog steeds net zo
>> traag.
>>
>> Opvallend is dat de voorpagina een stuk trager is dan andere
>> pagina's. De voorpagina heeft echt wel een vertraging ruim boven de
>> 20 seconden. Andere pagina's laten je ongeveer 10 seconden wachten.
>>
>> Iemand een idee?
>
> 20 sec riekt wel erg naar wachten op een antwoord van iets, Wat zegt de
> log van je DNS vanaf die host?
Hoe kan ik dat het beste bekijken?
> Paul van der Vlis <pa...@vandervlis.nl> wrote:
>
>> Ik heb hem ook nog overgezet naar een andere domeinnaam, compleet met
>> SSL-certificaat wat nu goed werkt. Maar hij is nog steeds net zo
>> traag.
>>
>> Opvallend is dat de voorpagina een stuk trager is dan andere
>> pagina's. De voorpagina heeft echt wel een vertraging ruim boven de
>> 20 seconden. Andere pagina's laten je ongeveer 10 seconden wachten.
>>
>> Iemand een idee?
>
> 20 sec riekt wel erg naar wachten op een antwoord van iets, Wat zegt de
> log van je DNS vanaf die host?
Ik heb in de logs van mijn bind9 server gekeken, maar die logt zoiets
niet. Misschien kan hij ook meer verbose loggen.
Of door het netwerkverkeer te monitoren? (niet mijn sterke kant...)
> Staat die server soms in een DMZ en wil
> hij bijvoorbeeld een CRL ophalen o.i.d. wat-ie niet mag van de firewall?
Het lijkt geen SSL probleem. Ik heb hem ook zonder SSL gedraaid en toen
was hij net zo traag.
Op diezelfde machine draai ik ook allerlei andere sites en die doen het
prima. Het is mijn shared hosting server.
https://vandervlis.nl draait er ook op, en ook vele Wordpress sites.
> Wil hij misschien ipv6 gebruiken en dat mag/kan ergens in het
> path niet?
> Het zijn lastige dingen in ieder geval.
2 seconden bij een reload, dat lijkt me toch niet echt alarmerend.
Ik weet het ook even niet.
Richard Lucassen
Feb 2, 2024, 10:29:14 AM2/2/24
to
On Fri, 2 Feb 2024 00:53:16 +0100
Paul van der Vlis <pa...@vandervlis.nl> wrote:
> > 20 sec riekt wel erg naar wachten op een antwoord van iets, Wat
> > zegt de log van je DNS vanaf die host?
>
> Hoe kan ik dat het beste bekijken?
Ik zoek dan in de logs op SERVFAIL, dan is er iets aan een server
Paul van der Vlis <pa...@vandervlis.nl> wrote:
> > 20 sec riekt wel erg naar wachten op een antwoord van iets, Wat
> > zegt de log van je DNS vanaf die host?
>
> Hoe kan ik dat het beste bekijken?
gevraagd die niet bestaat of eventueel op NXDOMAIN
> Ik heb in de logs van mijn bind9 server gekeken, maar die logt zoiets
> niet. Misschien kan hij ook meer verbose loggen.
> Of door het netwerkverkeer te monitoren? (niet mijn sterke kant...)
Of met -v zie je meer.
> > Staat die server soms in een DMZ en wil
> > hij bijvoorbeeld een CRL ophalen o.i.d. wat-ie niet mag van de
> > firewall?
>
> Alles staat in het datacenter.
> Het lijkt geen SSL probleem. Ik heb hem ook zonder SSL gedraaid en
> toen was hij net zo traag.
> Op diezelfde machine draai ik ook allerlei andere sites en die doen
> het prima. Het is mijn shared hosting server.
> https://vandervlis.nl draait er ook op, en ook vele Wordpress sites.
>
> > Wil hij misschien ipv6 gebruiken en dat mag/kan ergens in het
> > path niet?
>
> IPv6 doet het prima...
>
> > Het zijn lastige dingen in ieder geval.
>
> Ik log de "slow queries" boven 1 seconde. Ik zie een query van
> ongeveer 2 seconden bij een reload, dat lijkt me toch niet echt
> alarmerend.
>
> Ik weet het ook even niet.
me. Als het een vast draaiend proces is zou je nog wat kunnen stracen;
strace -p <pid> -o /tmp/strace.txt -f
Maar ja, speld, hooiberg en je weet dan nog niet waar de hooiberg staat.
Bovendien zal die machine erg druk met van alles zijn neem ik aan. Maar
waarom doet hij een "reload"?
--
Richard Lucassen <mailin...@lucassen.org>
De ongekruisigde (ds. dr. in de kerk van Roodkapje)
Feb 2, 2024, 12:45:21 PM2/2/24
to
On 2024-01-30, Paul van der Vlis <pa...@vandervlis.nl> wrote:
> Hoi,
>
> Ik heb een Wordpress site verhuist van een gespecialiseerde provider
> naar mijn webserver. Eerst voor test, dus ik kan hem alleen zien via een
> aangepast hosts-bestand.
>
> Maar hij is nu erg traag, het laden van de eerste pagina duurt soms meer
> dan 25 seconden... Mijn webserver is behoorlijk snel omdat alles op NVMe
> staat, dus er klopt ergens iets niet.
>
> +++
> Hoi,
>
> Ik heb een Wordpress site verhuist van een gespecialiseerde provider
> naar mijn webserver. Eerst voor test, dus ik kan hem alleen zien via een
> aangepast hosts-bestand.
>
> Maar hij is nu erg traag, het laden van de eerste pagina duurt soms meer
> dan 25 seconden... Mijn webserver is behoorlijk snel omdat alles op NVMe
> staat, dus er klopt ergens iets niet.
>
>
> Heeft hier iemand nog een idee wat er kan zijn? Hij doet het dus wel
> correct, maar hij laadt heel erg traag...
Te weinig geheugen (RAM) waardoor hij continu aan het swappen is?
> Heeft hier iemand nog een idee wat er kan zijn? Hij doet het dus wel
> correct, maar hij laadt heel erg traag...
Paul van der Vlis
Feb 4, 2024, 4:11:25 AM2/4/24
to
Op 02-02-2024 om 18:45 schreef De ongekruisigde (ds. dr. in de kerk van
Roodkapje):
Zoals ik al zei is het een shared hostingserver waarop allerlei sites
prima draaien. Dus nee, hij is niet aan het swappen.
Roodkapje):
prima draaien. Dus nee, hij is niet aan het swappen.
Paul van der Vlis
Feb 4, 2024, 4:44:34 AM2/4/24
to
Op 02-02-2024 om 16:29 schreef Richard Lucassen:
alles wat er niets mee te maken heeft weggehaald.
De DNS is nu overigens overgezet op mijn machine omdat de originele
hoster het niet meer deed. Dus alles staat nu echt online maar is heel
traag. Iets minder traag weliswaar, een reload van de pagina in de
browser duurt nu ongeveer 20 seconden.
Ik zie dat hij steeds eerst een "bad udp cksum" geeft, dan doet hij het
nog een keer, en die tweede keer is het goed. Lijkt me niet goed, maar
heeft hiermee wellicht weinig te maken.
> Of met -v zie je meer.
Dit is met -v:
----
10:34:21.271056 IP6 (flowlabel 0x09a3e, hlim 64, next-header UDP (17)
payload length: 40) 2a01:1b0:7999:424::59.47865 >
2a01:1b0:7999:424::58.53: [bad udp cksum 0x53c7 -> 0x00ae!] 30538+ A?
mydomain.nl. (32)
10:34:21.271076 IP6 (flowlabel 0xc3062, hlim 64, next-header UDP (17)
payload length: 40) 2a01:1b0:7999:424::59.56527 >
2a01:1b0:7999:424::58.53: [bad udp cksum 0x53c7 -> 0xa699!] 44936+ A?
mydomain.nl. (32)
10:34:21.271078 IP6 (flowlabel 0xc3062, hlim 64, next-header UDP (17)
payload length: 40) 2a01:1b0:7999:424::59.56527 >
2a01:1b0:7999:424::58.53: [bad udp cksum 0x53c7 -> 0x8279!] 54157+ AAAA?
mydomain.nl. (32)
10:34:21.271088 IP6 (flowlabel 0x09a3e, hlim 64, next-header UDP (17)
payload length: 40) 2a01:1b0:7999:424::59.47865 >
2a01:1b0:7999:424::58.53: [bad udp cksum 0x53c7 -> 0x1e3b!] 22946+ AAAA?
mydomain.nl. (32)
10:34:21.271855 IP6 (flowlabel 0x4604b, hlim 64, next-header UDP (17)
payload length: 56) 2a01:1b0:7999:424::58.53 >
2a01:1b0:7999:424::59.47865: [udp sum ok] 30538* 1/0/0 mydomain.nl. A
91.198.178.59 (48)
10:34:21.271855 IP6 (flowlabel 0x39b2f, hlim 64, next-header UDP (17)
payload length: 56) 2a01:1b0:7999:424::58.53 >
2a01:1b0:7999:424::59.56527: [udp sum ok] 44936* 1/0/0 mydomain.nl. A
91.198.178.59 (48)
10:34:21.271956 IP6 (flowlabel 0x39b2f, hlim 64, next-header UDP (17)
payload length: 68) 2a01:1b0:7999:424::58.53 >
2a01:1b0:7999:424::59.56527: [udp sum ok] 54157* 1/0/0 mydomain.nl. AAAA
2a01:1b0:7999:424::59 (60)
10:34:21.271956 IP6 (flowlabel 0x4604b, hlim 64, next-header UDP (17)
payload length: 68) 2a01:1b0:7999:424::58.53 >
2a01:1b0:7999:424::59.47865: [udp sum ok] 22946* 1/0/0 mydomain.nl. AAAA
2a01:1b0:7999:424::59 (60)
10:34:21.301336 IP6 (flowlabel 0x64cae, hlim 64, next-header UDP (17)
payload length: 40) 2a01:1b0:7999:424::59.60662 >
2a01:1b0:7999:424::58.53: [bad udp cksum 0x53c7 -> 0x9905!] 44277+ A?
mydomain.nl. (32)
10:34:21.301364 IP6 (flowlabel 0x64cae, hlim 64, next-header UDP (17)
payload length: 40) 2a01:1b0:7999:424::59.60662 >
2a01:1b0:7999:424::58.53: [bad udp cksum 0x53c7 -> 0xabe1!] 39422+ AAAA?
mydomain.nl. (32)
10:34:21.302046 IP6 (flowlabel 0x291f6, hlim 64, next-header UDP (17)
payload length: 56) 2a01:1b0:7999:424::58.53 >
2a01:1b0:7999:424::59.60662: [udp sum ok] 44277* 1/0/0 mydomain.nl. A
91.198.178.59 (48)
10:34:21.302046 IP6 (flowlabel 0x291f6, hlim 64, next-header UDP (17)
payload length: 68) 2a01:1b0:7999:424::58.53 >
2a01:1b0:7999:424::59.60662: [udp sum ok] 39422* 1/0/0 mydomain.nl. AAAA
2a01:1b0:7999:424::59 (60)
-------
>>> Staat die server soms in een DMZ en wil
>>> hij bijvoorbeeld een CRL ophalen o.i.d. wat-ie niet mag van de
>>> firewall?
>>
>> Alles staat in het datacenter.
>
> Ook in DC's staan fw's ;-)
Bij mij is het vrij overzichtelijk. Uitgaand verkeer en antwoorden
daarop staan op deze machine open.
>> Het lijkt geen SSL probleem. Ik heb hem ook zonder SSL gedraaid en
>> toen was hij net zo traag.
>
> Ja, en hij haalt niet bij ioedere query een CRL op lijkt me
Inderdaad.
>> Op diezelfde machine draai ik ook allerlei andere sites en die doen
>> het prima. Het is mijn shared hosting server.
>> https://vandervlis.nl draait er ook op, en ook vele Wordpress sites.
>>
>>> Wil hij misschien ipv6 gebruiken en dat mag/kan ergens in het
>>> path niet?
>>
>> IPv6 doet het prima...
>>
>>> Het zijn lastige dingen in ieder geval.
>>
>> Ik log de "slow queries" boven 1 seconde. Ik zie een query van
>> ongeveer 2 seconden bij een reload, dat lijkt me toch niet echt
>> alarmerend.
>>
>> Ik weet het ook even niet.
>
> Het zijn ook complexe systemen die je niet even snel kan debuggen lijkt
> me. Als het een vast draaiend proces is zou je nog wat kunnen stracen;
>
> strace -p <pid> -o /tmp/strace.txt -f
>
> Maar ja, speld, hooiberg en je weet dan nog niet waar de hooiberg staat.
>
> Bovendien zal die machine erg druk met van alles zijn neem ik aan. Maar
> waarom doet hij een "reload"?
Ik bedoel daarmee dat ik op de "reload" van de browser klik. En kijk hoe
snel de site er weer is.
> On Fri, 2 Feb 2024 00:53:16 +0100
> Paul van der Vlis <pa...@vandervlis.nl> wrote:
>
>>> 20 sec riekt wel erg naar wachten op een antwoord van iets, Wat
>>> zegt de log van je DNS vanaf die host?
>>
>> Hoe kan ik dat het beste bekijken?
>
> Ik zoek dan in de logs op SERVFAIL, dan is er iets aan een server
> gevraagd die niet bestaat of eventueel op NXDOMAIN
>
>> Ik heb in de logs van mijn bind9 server gekeken, maar die logt zoiets
>> niet. Misschien kan hij ook meer verbose loggen.
>
> Ik ken eigenlijk alleen maar unbound
>
>> Of door het netwerkverkeer te monitoren? (niet mijn sterke kant...)
>
> tcpdump -ni eth0 udp port 53
Wel interessant om te zien wat er gebeurd. In onderstaande dump heb ik
> Paul van der Vlis <pa...@vandervlis.nl> wrote:
>
>>> 20 sec riekt wel erg naar wachten op een antwoord van iets, Wat
>>> zegt de log van je DNS vanaf die host?
>>
>> Hoe kan ik dat het beste bekijken?
>
> Ik zoek dan in de logs op SERVFAIL, dan is er iets aan een server
> gevraagd die niet bestaat of eventueel op NXDOMAIN
>
>> Ik heb in de logs van mijn bind9 server gekeken, maar die logt zoiets
>> niet. Misschien kan hij ook meer verbose loggen.
>
> Ik ken eigenlijk alleen maar unbound
>
>> Of door het netwerkverkeer te monitoren? (niet mijn sterke kant...)
>
> tcpdump -ni eth0 udp port 53
alles wat er niets mee te maken heeft weggehaald.
De DNS is nu overigens overgezet op mijn machine omdat de originele
hoster het niet meer deed. Dus alles staat nu echt online maar is heel
traag. Iets minder traag weliswaar, een reload van de pagina in de
browser duurt nu ongeveer 20 seconden.
Ik zie dat hij steeds eerst een "bad udp cksum" geeft, dan doet hij het
nog een keer, en die tweede keer is het goed. Lijkt me niet goed, maar
heeft hiermee wellicht weinig te maken.
> Of met -v zie je meer.
----
10:34:21.271056 IP6 (flowlabel 0x09a3e, hlim 64, next-header UDP (17)
payload length: 40) 2a01:1b0:7999:424::59.47865 >
2a01:1b0:7999:424::58.53: [bad udp cksum 0x53c7 -> 0x00ae!] 30538+ A?
mydomain.nl. (32)
10:34:21.271076 IP6 (flowlabel 0xc3062, hlim 64, next-header UDP (17)
payload length: 40) 2a01:1b0:7999:424::59.56527 >
2a01:1b0:7999:424::58.53: [bad udp cksum 0x53c7 -> 0xa699!] 44936+ A?
mydomain.nl. (32)
10:34:21.271078 IP6 (flowlabel 0xc3062, hlim 64, next-header UDP (17)
payload length: 40) 2a01:1b0:7999:424::59.56527 >
2a01:1b0:7999:424::58.53: [bad udp cksum 0x53c7 -> 0x8279!] 54157+ AAAA?
mydomain.nl. (32)
10:34:21.271088 IP6 (flowlabel 0x09a3e, hlim 64, next-header UDP (17)
payload length: 40) 2a01:1b0:7999:424::59.47865 >
2a01:1b0:7999:424::58.53: [bad udp cksum 0x53c7 -> 0x1e3b!] 22946+ AAAA?
mydomain.nl. (32)
10:34:21.271855 IP6 (flowlabel 0x4604b, hlim 64, next-header UDP (17)
payload length: 56) 2a01:1b0:7999:424::58.53 >
2a01:1b0:7999:424::59.47865: [udp sum ok] 30538* 1/0/0 mydomain.nl. A
91.198.178.59 (48)
10:34:21.271855 IP6 (flowlabel 0x39b2f, hlim 64, next-header UDP (17)
payload length: 56) 2a01:1b0:7999:424::58.53 >
2a01:1b0:7999:424::59.56527: [udp sum ok] 44936* 1/0/0 mydomain.nl. A
91.198.178.59 (48)
10:34:21.271956 IP6 (flowlabel 0x39b2f, hlim 64, next-header UDP (17)
payload length: 68) 2a01:1b0:7999:424::58.53 >
2a01:1b0:7999:424::59.56527: [udp sum ok] 54157* 1/0/0 mydomain.nl. AAAA
2a01:1b0:7999:424::59 (60)
10:34:21.271956 IP6 (flowlabel 0x4604b, hlim 64, next-header UDP (17)
payload length: 68) 2a01:1b0:7999:424::58.53 >
2a01:1b0:7999:424::59.47865: [udp sum ok] 22946* 1/0/0 mydomain.nl. AAAA
2a01:1b0:7999:424::59 (60)
10:34:21.301336 IP6 (flowlabel 0x64cae, hlim 64, next-header UDP (17)
payload length: 40) 2a01:1b0:7999:424::59.60662 >
2a01:1b0:7999:424::58.53: [bad udp cksum 0x53c7 -> 0x9905!] 44277+ A?
mydomain.nl. (32)
10:34:21.301364 IP6 (flowlabel 0x64cae, hlim 64, next-header UDP (17)
payload length: 40) 2a01:1b0:7999:424::59.60662 >
2a01:1b0:7999:424::58.53: [bad udp cksum 0x53c7 -> 0xabe1!] 39422+ AAAA?
mydomain.nl. (32)
10:34:21.302046 IP6 (flowlabel 0x291f6, hlim 64, next-header UDP (17)
payload length: 56) 2a01:1b0:7999:424::58.53 >
2a01:1b0:7999:424::59.60662: [udp sum ok] 44277* 1/0/0 mydomain.nl. A
91.198.178.59 (48)
10:34:21.302046 IP6 (flowlabel 0x291f6, hlim 64, next-header UDP (17)
payload length: 68) 2a01:1b0:7999:424::58.53 >
2a01:1b0:7999:424::59.60662: [udp sum ok] 39422* 1/0/0 mydomain.nl. AAAA
2a01:1b0:7999:424::59 (60)
-------
>>> Staat die server soms in een DMZ en wil
>>> hij bijvoorbeeld een CRL ophalen o.i.d. wat-ie niet mag van de
>>> firewall?
>>
>> Alles staat in het datacenter.
>
> Ook in DC's staan fw's ;-)
daarop staan op deze machine open.
>> Het lijkt geen SSL probleem. Ik heb hem ook zonder SSL gedraaid en
>> toen was hij net zo traag.
>
> Ja, en hij haalt niet bij ioedere query een CRL op lijkt me
>> Op diezelfde machine draai ik ook allerlei andere sites en die doen
>> het prima. Het is mijn shared hosting server.
>> https://vandervlis.nl draait er ook op, en ook vele Wordpress sites.
>>
>>> Wil hij misschien ipv6 gebruiken en dat mag/kan ergens in het
>>> path niet?
>>
>> IPv6 doet het prima...
>>
>>> Het zijn lastige dingen in ieder geval.
>>
>> Ik log de "slow queries" boven 1 seconde. Ik zie een query van
>> ongeveer 2 seconden bij een reload, dat lijkt me toch niet echt
>> alarmerend.
>>
>> Ik weet het ook even niet.
>
> Het zijn ook complexe systemen die je niet even snel kan debuggen lijkt
> me. Als het een vast draaiend proces is zou je nog wat kunnen stracen;
>
> strace -p <pid> -o /tmp/strace.txt -f
>
> Maar ja, speld, hooiberg en je weet dan nog niet waar de hooiberg staat.
>
> Bovendien zal die machine erg druk met van alles zijn neem ik aan. Maar
> waarom doet hij een "reload"?
snel de site er weer is.
Wil Taphoorn
Feb 4, 2024, 9:51:48 AM2/4/24
to
On 4-2-2024 10:44, Paul van der Vlis wrote:
> Ik zie dat hij steeds eerst een "bad udp cksum" geeft, dan doet hij het
> nog een keer, en die tweede keer is het goed.
Die "tweede keer goed" is niet te zien. De dump zegt dat de client
> Ik zie dat hij steeds eerst een "bad udp cksum" geeft, dan doet hij het
> nog een keer, en die tweede keer is het goed.
in drie sessies om A en AAAA records van zichzelf vraagt, *alle* zes
aanvragen met foute checksum. Dat de server op deze zes aanvragen
toch het goede antwoord geeft snap ik dan weer niet.
Kijk maar: (volgorde niet veranderd, sessienummers ervoor gezet)
1 client.47865 > server.53 [bad udp cksum} A?mydomain.nl.
2 client.56527 > server.53 [bad udp cksum} A?mydomain.nl.
2 client.56527 > server.53 [bad udp cksum} AAAA?mydomain.nl.
1 client.47865 > server.53 [bad udp cksum} AAAA?mydomain.nl.
1 server.53 > client.47865 [udp sum ok] mydomain.nl. A91.~~.59
2 server.53 > client.56527 [udp sum ok] mydomain.nl. A91.~~.59
2 server.53 > client.56527 [udp sum ok] mydomain.nl. AAAA2a01:~~::59
1 server.53 > client.47865 [udp sum ok] mydomain.nl. AAAA2a01:~~::59
3 client.60662 > server.53 [bad udp cksum} A?mydomain.nl.
3 client.60662 > server.53 [bad udp cksum} AAAA?mydomain.nl.
3 server.53 > client.60662 [udp sum ok] mydomain.nl. A91.~~.59
3 server.53 > client.60662 [udp sum ok] mydomain.nl. AAAA2a01:~~::59
--
wil
Richard Lucassen
Feb 4, 2024, 5:01:26 PM2/4/24
to
On Sun, 4 Feb 2024 10:44:30 +0100
Paul van der Vlis <pa...@vandervlis.nl> wrote:
> > tcpdump -ni eth0 udp port 53
>
> Wel interessant om te zien wat er gebeurd. In onderstaande dump heb
> ik alles wat er niets mee te maken heeft weggehaald.
>
> De DNS is nu overigens overgezet op mijn machine omdat de originele
> hoster het niet meer deed. Dus alles staat nu echt online maar is
> heel traag. Iets minder traag weliswaar, een reload van de pagina in
> de browser duurt nu ongeveer 20 seconden.
>
> Ik zie dat hij steeds eerst een "bad udp cksum" geeft, dan doet hij
> het nog een keer, en die tweede keer is het goed. Lijkt me niet goed,
> maar heeft hiermee wellicht weinig te maken.
Zet dat mydomain.nl eens in /etc/hosts met alleen het ipv4 nummer (en
Paul van der Vlis <pa...@vandervlis.nl> wrote:
> > tcpdump -ni eth0 udp port 53
>
> Wel interessant om te zien wat er gebeurd. In onderstaande dump heb
> ik alles wat er niets mee te maken heeft weggehaald.
>
> De DNS is nu overigens overgezet op mijn machine omdat de originele
> hoster het niet meer deed. Dus alles staat nu echt online maar is
> heel traag. Iets minder traag weliswaar, een reload van de pagina in
> de browser duurt nu ongeveer 20 seconden.
>
> Ik zie dat hij steeds eerst een "bad udp cksum" geeft, dan doet hij
> het nog een keer, en die tweede keer is het goed. Lijkt me niet goed,
> maar heeft hiermee wellicht weinig te maken.
eventueel later ook ipv6) Als het goed is gebruikt-ie dan de dns niet
meer voor dat domain.
Dit zie ik;
# tcpdump -vni wlan0 udp port 53
tcpdump: listening on wlan0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
22:58:55.931258 IP (tos 0x0, ttl 64, id 60739, offset 0, flags [none], proto UDP (17), length 57)
192.168.66.252.51184 > 192.168.64.1.53: 10258+ A? mydomain.nl. (29)
22:58:55.936485 IP (tos 0x0, ttl 64, id 63622, offset 0, flags [none], proto UDP (17), length 73)
192.168.64.1.53 > 192.168.66.252.51184: 10258 1/0/0 mydomain.nl. A 92.63.163.157 (45)
22:58:55.937490 IP (tos 0x0, ttl 64, id 8767, offset 0, flags [none], proto UDP (17), length 57)
192.168.66.252.41981 > 192.168.64.1.53: 4363+ AAAA? mydomain.nl. (29)
22:58:55.939617 IP (tos 0x0, ttl 64, id 63624, offset 0, flags [none], proto UDP (17), length 85)
192.168.64.1.53 > 192.168.66.252.41981: 4363 1/0/0 mydomain.nl. AAAA 2a01:a680:a1:d::157 (57)
22:58:55.940446 IP (tos 0x0, ttl 64, id 55214, offset 0, flags [none], proto UDP (17), length 57)
192.168.66.252.50626 > 192.168.64.1.53: 23829+ MX? mydomain.nl. (29)
22:58:55.943856 IP (tos 0x0, ttl 64, id 63625, offset 0, flags [none], proto UDP (17), length 72)
192.168.64.1.53 > 192.168.66.252.50626: 23829 1/0/0 mydomain.nl. MX . 0 (44)
> > Ook in DC's staan fw's ;-)
>
> Bij mij is het vrij overzichtelijk. Uitgaand verkeer en antwoorden
> daarop staan op deze machine open.
heen. Ik zet een webserver altijd in een DMZ, zodat ze er zo weinig
mogelijk aan hebben als ik een onbedoelde extra root admin aan boord
heb ;-)
R.
--
Richard Lucassen <mailin...@lucassen.org>
Paul van der Vlis
Feb 5, 2024, 5:30:58 AM2/5/24
to
Op 04-02-2024 om 23:01 schreef Richard Lucassen:
aan de DNS.
Maar hij wordt er niet sneller van. Ook niet als er zowel een IPv4 als
een IPv6 in /etc/hosts staat.
Hij is nu overigens wel iets sneller dan voorheen, maar een reload van
de browser duurt nog altijd ca 19 seconden.
> Dit zie ik;
>
> # tcpdump -vni wlan0 udp port 53
> tcpdump: listening on wlan0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
> 22:58:55.931258 IP (tos 0x0, ttl 64, id 60739, offset 0, flags [none], proto UDP (17), length 57)
> 192.168.66.252.51184 > 192.168.64.1.53: 10258+ A? mydomain.nl. (29)
> 22:58:55.936485 IP (tos 0x0, ttl 64, id 63622, offset 0, flags [none], proto UDP (17), length 73)
> 192.168.64.1.53 > 192.168.66.252.51184: 10258 1/0/0 mydomain.nl. A 92.63.163.157 (45)
> 22:58:55.937490 IP (tos 0x0, ttl 64, id 8767, offset 0, flags [none], proto UDP (17), length 57)
> 192.168.66.252.41981 > 192.168.64.1.53: 4363+ AAAA? mydomain.nl. (29)
> 22:58:55.939617 IP (tos 0x0, ttl 64, id 63624, offset 0, flags [none], proto UDP (17), length 85)
> 192.168.64.1.53 > 192.168.66.252.41981: 4363 1/0/0 mydomain.nl. AAAA 2a01:a680:a1:d::157 (57)
> 22:58:55.940446 IP (tos 0x0, ttl 64, id 55214, offset 0, flags [none], proto UDP (17), length 57)
> 192.168.66.252.50626 > 192.168.64.1.53: 23829+ MX? mydomain.nl. (29)
> 22:58:55.943856 IP (tos 0x0, ttl 64, id 63625, offset 0, flags [none], proto UDP (17), length 72)
> 192.168.64.1.53 > 192.168.66.252.50626: 23829 1/0/0 mydomain.nl. MX . 0 (44)
>
>>> Ook in DC's staan fw's ;-)
>>
>> Bij mij is het vrij overzichtelijk. Uitgaand verkeer en antwoorden
>> daarop staan op deze machine open.
>
> Ja, dus een Rus die je machine hackt heeft vrij spel, hij mag overal
> heen. Ik zet een webserver altijd in een DMZ, zodat ze er zo weinig
> mogelijk aan hebben als ik een onbedoelde extra root admin aan boord
> heb ;-)
Ik doe dat ook op sommige machines, maar niet op deze.
Ik vind het in de praktijk nogal lastig overigens, daarom heb ik op deze
machine andere methoden me te beschermen.
> On Sun, 4 Feb 2024 10:44:30 +0100
> Paul van der Vlis <pa...@vandervlis.nl> wrote:
>
>>> tcpdump -ni eth0 udp port 53
>>
>> Wel interessant om te zien wat er gebeurd. In onderstaande dump heb
>> ik alles wat er niets mee te maken heeft weggehaald.
>>
>> De DNS is nu overigens overgezet op mijn machine omdat de originele
>> hoster het niet meer deed. Dus alles staat nu echt online maar is
>> heel traag. Iets minder traag weliswaar, een reload van de pagina in
>> de browser duurt nu ongeveer 20 seconden.
>>
>> Ik zie dat hij steeds eerst een "bad udp cksum" geeft, dan doet hij
>> het nog een keer, en die tweede keer is het goed. Lijkt me niet goed,
>> maar heeft hiermee wellicht weinig te maken.
>
> Zet dat mydomain.nl eens in /etc/hosts met alleen het ipv4 nummer (en
> eventueel later ook ipv6) Als het goed is gebruikt-ie dan de dns niet
> meer voor dat domain.
Inderdaad, en als er een IPv4 staat dan vraagt hij ook niet om een IPv6
> Paul van der Vlis <pa...@vandervlis.nl> wrote:
>
>>> tcpdump -ni eth0 udp port 53
>>
>> Wel interessant om te zien wat er gebeurd. In onderstaande dump heb
>> ik alles wat er niets mee te maken heeft weggehaald.
>>
>> De DNS is nu overigens overgezet op mijn machine omdat de originele
>> hoster het niet meer deed. Dus alles staat nu echt online maar is
>> heel traag. Iets minder traag weliswaar, een reload van de pagina in
>> de browser duurt nu ongeveer 20 seconden.
>>
>> Ik zie dat hij steeds eerst een "bad udp cksum" geeft, dan doet hij
>> het nog een keer, en die tweede keer is het goed. Lijkt me niet goed,
>> maar heeft hiermee wellicht weinig te maken.
>
> Zet dat mydomain.nl eens in /etc/hosts met alleen het ipv4 nummer (en
> eventueel later ook ipv6) Als het goed is gebruikt-ie dan de dns niet
> meer voor dat domain.
aan de DNS.
Maar hij wordt er niet sneller van. Ook niet als er zowel een IPv4 als
een IPv6 in /etc/hosts staat.
Hij is nu overigens wel iets sneller dan voorheen, maar een reload van
de browser duurt nog altijd ca 19 seconden.
> Dit zie ik;
>
> # tcpdump -vni wlan0 udp port 53
> tcpdump: listening on wlan0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
> 22:58:55.931258 IP (tos 0x0, ttl 64, id 60739, offset 0, flags [none], proto UDP (17), length 57)
> 192.168.66.252.51184 > 192.168.64.1.53: 10258+ A? mydomain.nl. (29)
> 22:58:55.936485 IP (tos 0x0, ttl 64, id 63622, offset 0, flags [none], proto UDP (17), length 73)
> 192.168.64.1.53 > 192.168.66.252.51184: 10258 1/0/0 mydomain.nl. A 92.63.163.157 (45)
> 22:58:55.937490 IP (tos 0x0, ttl 64, id 8767, offset 0, flags [none], proto UDP (17), length 57)
> 192.168.66.252.41981 > 192.168.64.1.53: 4363+ AAAA? mydomain.nl. (29)
> 22:58:55.939617 IP (tos 0x0, ttl 64, id 63624, offset 0, flags [none], proto UDP (17), length 85)
> 192.168.64.1.53 > 192.168.66.252.41981: 4363 1/0/0 mydomain.nl. AAAA 2a01:a680:a1:d::157 (57)
> 22:58:55.940446 IP (tos 0x0, ttl 64, id 55214, offset 0, flags [none], proto UDP (17), length 57)
> 192.168.66.252.50626 > 192.168.64.1.53: 23829+ MX? mydomain.nl. (29)
> 22:58:55.943856 IP (tos 0x0, ttl 64, id 63625, offset 0, flags [none], proto UDP (17), length 72)
> 192.168.64.1.53 > 192.168.66.252.50626: 23829 1/0/0 mydomain.nl. MX . 0 (44)
>
>>> Ook in DC's staan fw's ;-)
>>
>> Bij mij is het vrij overzichtelijk. Uitgaand verkeer en antwoorden
>> daarop staan op deze machine open.
>
> Ja, dus een Rus die je machine hackt heeft vrij spel, hij mag overal
> heen. Ik zet een webserver altijd in een DMZ, zodat ze er zo weinig
> mogelijk aan hebben als ik een onbedoelde extra root admin aan boord
> heb ;-)
Ik vind het in de praktijk nogal lastig overigens, daarom heb ik op deze
machine andere methoden me te beschermen.
Paul van der Vlis
Feb 5, 2024, 5:46:12 AM2/5/24
to
Op 04-02-2024 om 15:51 schreef Wil Taphoorn:
Je hebt gelijk, het zijn steeds de aanvragen.
Ik moet hier een keer naar kijken.
Maar andere sites hebben hetzelfde op deze machine, dit is niet de
veroorzaker van het probleem van de trage site.
Ik moet hier een keer naar kijken.
Maar andere sites hebben hetzelfde op deze machine, dit is niet de
veroorzaker van het probleem van de trage site.
Paul van der Vlis
Feb 7, 2024, 5:57:31 PM2/7/24
to
Op 30-01-2024 om 16:24 schreef Paul van der Vlis:
<knip>
Ik ben eruit gekomen door alle plugins te verwijderen op een
testmachine, en ze in kleine porties weer terug te zetten.
Ik deed het door de plugins directory leeg te maken, maar ik had net zo
goed alle plugins kunnen disabelen in de webinterface denk ik achteraf.
Wel belangrijk goed te noteren welke plugins al gedisabled waren, die
moet je natuurlijk niet gaan enabelen.
Het probleem bleek te komen door de plugin "Happy Elementor Addons Pro".
Alhoewel... op de testmachine (Debian 12) was het probleem hiermee
opgelost. Op de productiemachine (Debian 11) niet. Dus ik heb van de
testmachine de productiemachine gemaakt door de DNS te veranderen.
Ik wou wellicht nog wel uitzoeken wat het probleem op de voormalige
productiemachine was. Maar hij doet het nu in elk geval snel ;-)
<knip>
Ik ben eruit gekomen door alle plugins te verwijderen op een
testmachine, en ze in kleine porties weer terug te zetten.
Ik deed het door de plugins directory leeg te maken, maar ik had net zo
goed alle plugins kunnen disabelen in de webinterface denk ik achteraf.
Wel belangrijk goed te noteren welke plugins al gedisabled waren, die
moet je natuurlijk niet gaan enabelen.
Het probleem bleek te komen door de plugin "Happy Elementor Addons Pro".
Alhoewel... op de testmachine (Debian 12) was het probleem hiermee
opgelost. Op de productiemachine (Debian 11) niet. Dus ik heb van de
testmachine de productiemachine gemaakt door de DNS te veranderen.
Ik wou wellicht nog wel uitzoeken wat het probleem op de voormalige
productiemachine was. Maar hij doet het nu in elk geval snel ;-)
0 new messages