{"id":21491,"date":"2026-09-17T15:05:11","date_gmt":"2026-09-17T13:05:11","guid":{"rendered":"https:\/\/webhosting.de\/apache-scoreboard-serverauslastung-im-detail-monitoring\/"},"modified":"2026-09-17T15:05:11","modified_gmt":"2026-09-17T13:05:11","slug":"apache-scoreboard-detaljeret-overvagning-af-serverbelastningen","status":"publish","type":"post","link":"https:\/\/webhosting.de\/da\/apache-scoreboard-serverauslastung-im-detail-monitoring\/","title":{"rendered":"Apache Scoreboard: En detaljeret forst\u00e5else af serverbelastningen"},"content":{"rendered":"<p>Apache Scoreboard viser mig i realtid, hvor mange workers der lige nu l\u00e6ser foresp\u00f8rgsler, sender svar eller venter i tomgang, og jeg bruger det til at vurdere <strong>Serverbelastning<\/strong> uden g\u00e6tterier. Via mod_status f\u00e5r jeg struktureret adgang til statusdataene, fortolker symboler, m\u00e5ler gennemstr\u00f8mningen og udleder heraf konkrete <strong>Trin i tuningen<\/strong> fra.<\/p>\n\n<h2>Centrale punkter<\/h2>\n\n<ul>\n  <li><strong>Status i realtid<\/strong> alle medarbejdere forst\u00e5r og hurtigt kan identificere flaskehalse.<\/li>\n  <li><strong>mod_status<\/strong> Sikre driften og udnytte ExtendedStatus p\u00e5 en fornuftig m\u00e5de.<\/li>\n  <li><strong>N\u00f8gletal<\/strong> hvordan man systematisk analyserer Req\/s, Busy\/Idle og CPU.<\/li>\n  <li><strong>Symboler<\/strong> fortolke resultattavlen og handle m\u00e5lrettet.<\/li>\n  <li><strong>Overv\u00e5gning<\/strong> automatisere og indstille alarmer p\u00e5 baggrund af data.<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/apache-serverraum-8371.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Hvad er Apache Scoreboard?<\/h2>\n\n<p>I Scoreboard gemmer Apache en aktuel status for hver worker, f.eks. \u00bbL\u00e6ser\u00ab, \u00bbSender\u00ab eller \u00bbInaktiv\u00ab, og dermed kan jeg se <strong>Arbejdsfordeling<\/strong> af processerne. Dataene findes internt og sendes via mod_status til brugergr\u00e6nsefladen, enten som HTML eller i maskinl\u00e6sbar form. Der tjekker jeg travle arbejdsprocesser, inaktive arbejdsprocesser, CPU-belastning, oppetid samt adgangsforesp\u00f8rgsler og bytes. Jeg finder is\u00e6r det meget detaljerede overblik over de enkelte workers nyttigt, fordi jeg kan se behandlingstid og aktiv host. P\u00e5 den m\u00e5de kan jeg tr\u00e6ffe en velbegrundet beslutning om, hvorvidt der mangler kapacitet, om foresp\u00f8rgsler tager for lang tid, eller om Keep-Alive-slots er blokeret; disse <strong>Gennemsigtighed<\/strong> sparer tid ved \u00e5rsagsanalysen.<\/p>\n\n<h2>S\u00e5dan f\u00e5r jeg adgang via mod_status<\/h2>\n\n<p>Via \/server-status \u00e5bner jeg en overskuelig HTML-side; via \/server-status?auto f\u00e5r jeg en kortfattet tekstudskrift for <strong>Overv\u00e5gning<\/strong> og scripts. I produktive milj\u00f8er aktiverer jeg ExtendedStatus On, fordi de ekstra m\u00e5linger pr. worker giver mig den n\u00f8dvendige kontekst. Jeg begr\u00e6nser adgangen strengt til administratornetv\u00e6rk eller enkelte v\u00e6rter og lader ikke siden v\u00e6re offentligt tilg\u00e6ngelig. Til en manuel gennemgang er en kort browsersession tilstr\u00e6kkelig, mens jeg ved l\u00f8bende overv\u00e5gning integrerer den automatiske visning i et overv\u00e5gningssystem. P\u00e5 den m\u00e5de holder jeg omkostningerne nede og sikrer <strong>statusdata<\/strong> er fornuftigt.<\/p>\n\n<h2>Vurdere sikker konfiguration og overhead<\/h2>\n\n<p>Jeg overv\u00e5ger \/server-status l\u00f8bende og v\u00e6lger alt efter situationen mellem IP-godkendelse, autentificering eller en intern admin-VHost. ExtendedStatus medf\u00f8rer en m\u00e5lbar, men i praksis ubetydelig <strong>Overhead<\/strong>; jeg aktiverer den permanent, hvis jeg ogs\u00e5 bruger dataene i overv\u00e5gningen, eller kun midlertidigt ved ad hoc-analyser. En overskuelig eksempelkonfiguration hj\u00e6lper mig med at undg\u00e5 fejl:<\/p>\n\n<pre><code>Aktiver #\nExtendedStatus On\n\nG\u00f8r #-status kun tilg\u00e6ngelig internt\n\n  SetHandler server-status\n\n  # Variant 1: IP-baseret\n  Require ip 10.0.0.0\/8 192.168.0.0\/16 ::1\n\n  # Variant 2: Basic-Auth (f.eks. i till\u00e6g til IP)\n  #AuthType Basic\n  #AuthName \"Server Status\"\n  #AuthUserFile \"\/etc\/httpd\/conf\/.htpasswd\"\n  #Require valid-user\n<\/code><\/pre>\n\n<p>Jeg s\u00f8rger for, at siden ogs\u00e5 er tilg\u00e6ngelig uden for produktions-VHosts (f.eks. via en intern adresse), s\u00e5 der ikke er nogen omskrivningsregler eller proxyruter, der forstyrrer. N\u00e5r jeg afslutter fejlfindingsfaserne, kontrollerer jeg, at kun de n\u00f8dvendige oplysninger offentligg\u00f8res.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/apache_serveranalyse_6874.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Hurtig gennemgang af resultattavlens symboler<\/h2>\n\n<p>N\u00e5r der opst\u00e5r forstyrrelser, kigger jeg f\u00f8rst p\u00e5 symbolerne, fordi et t\u00e6t m\u00f8nster af R og W afsl\u00f8rer akut belastning, mens mange _ signalerer ro; disse <strong>Kodning<\/strong> fremskynder diagnosen. K viser mig ogs\u00e5 \u00e5bne Keep-Alive-forbindelser, der binder arbejdere, hvis timeout-indstillingen er forkert. Et fokus p\u00e5 D indikerer DNS-opslag, der forsinker svarene. Hyppige L-poster tyder p\u00e5 blokerende logning og lagringsundersystemer. Med et par blik kan jeg s\u00e5ledes identificere den dominerende flaskehals og iv\u00e6rks\u00e6tte m\u00e5lrettede <strong>Foranstaltninger<\/strong>.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Symbol<\/th>\n      <th>Betydning<\/th>\n      <th>Hurtig meddelelse<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>_<\/td>\n      <td>Inaktiv medarbejder<\/td>\n      <td>Tilstr\u00e6kkelig <strong>Kapacitet<\/strong> til stede<\/td>\n    <\/tr>\n    <tr>\n      <td>R<\/td>\n      <td>Anmodning om l\u00e6sning<\/td>\n      <td>Kontroller netv\u00e6rksforsinkelsen, eller <strong>Kunde<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>W<\/td>\n      <td>Afsendelse af svar<\/td>\n      <td>Backend-tid og outputst\u00f8rrelse <strong>analysere<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>K<\/td>\n      <td>Keep-Alive<\/td>\n      <td>Timeouts og slot-binding <strong>kontrollere<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>D<\/td>\n      <td>DNS-opslag<\/td>\n      <td>Deaktivere reverse DNS eller <strong>Cache<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>L<\/td>\n      <td>Logning<\/td>\n      <td>Asynkron logning og <strong>I\/O<\/strong> Tjek<\/td>\n    <\/tr>\n    <tr>\n      <td>C<\/td>\n      <td>Afslutning<\/td>\n      <td>Normalt forbindelsesafslutning, <strong>kort<\/strong> synlig<\/td>\n    <\/tr>\n    <tr>\n      <td>G<\/td>\n      <td>En elegant afslutning<\/td>\n      <td>Afsluttet foresp\u00f8rgsel, Worker <strong>rydder op<\/strong> p\u00e5<\/td>\n    <\/tr>\n    <tr>\n      <td>I<\/td>\n      <td>Oprydning ved inaktivitet<\/td>\n      <td>Ukritisk, arbejdstager <strong>korrigeret<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>.<\/td>\n      <td>Inaktiv<\/td>\n      <td>En rolig periode, ressourcer <strong>gratis<\/strong><\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Genkende avancerede m\u00f8nstre og angrebsprofiler<\/h2>\n\n<p>Jeg vurderer ikke kun enkelte tilstande, men ogs\u00e5 <strong>Varighed<\/strong> og fordelingen af symbolerne. Mange langvarige R-tilstande kombineret med lav netv\u00e6rksb\u00e5ndbredde tyder p\u00e5 langsomme klienter eller Slowloris-m\u00f8nstre; i s\u00e5 fald begr\u00e6nser jeg l\u00e6setiderne pr. foresp\u00f8rgsel (f.eks. med RequestReadTimeout) og indstiller realistiske minimumsrater. Hvis W-tilstande med et h\u00f8jt antal bytes pr. foresp\u00f8rgsel dominerer, er det snarere b\u00e5ndbredden eller lagerpladsen, der er begr\u00e6nsende. Hvis der samtidig forekommer en ophobning af D- og L-tilstande, prioriterer jeg navneopl\u00f8sning og log-I\/O. Det afg\u00f8rende er, om m\u00f8nstre <strong>bred<\/strong> (alle medarbejdere) eller <strong>lokal<\/strong> (kun \u00e9n VHost eller sti) \u2013 p\u00e5 den m\u00e5de kan jeg hurtigere finde hotspots i applikationen.<\/p>\n\n<h2>N\u00f8gletal til analyse af webservere<\/h2>\n\n<p>Antallet af anmodninger pr. sekund viser mig gennemstr\u00f8mningen, men jeg vurderer samtidig antallet af byte pr. sekund og antallet af byte pr. anmodning for <strong>nyttelast<\/strong>. Forholdet mellem travlhed og inaktivitet afsl\u00f8rer, om der mangler slots, eller om indstillingerne er for konservative. Jeg korrelerer CPU-udnyttelsen med svartiderne for at skelne mellem CPU-begr\u00e6nsede og I\/O-begr\u00e6nsede situationer. Oppetiden hj\u00e6lper med at skelne mellem nye genstarter og reelle tendenser. Ud fra denne kombination udleder jeg konkrete optimeringsmuligheder for worker, keep-alive og <strong>Timeouts<\/strong> fra.<\/p>\n\n<h2>Gr\u00e6nsev\u00e6rdier og alarmering i praksis<\/h2>\n\n<p>Jeg indstiller alarmer ikke p\u00e5 basis af \u00f8jebliksv\u00e6rdier, men p\u00e5 basis af glidende gennemsnit og <strong>Varighed<\/strong>. F\u00f8lgende heuristikker har f.eks. vist sig at fungere godt: Idle  4:1 over samme tidsrum tyder p\u00e5 overbelastning. Req\/s falder ved konstant trafik, mens \u00bbBusy\u00ab forbliver konstant \u2013 s\u00e5 ligger der ofte et backend-problem bag. K-andel &gt; 50 % i primetime tyder p\u00e5 for gener\u00f8s keep-alive. Jeg supplerer t\u00e6rskelv\u00e6rdierne med trendalarmer (stigende svartider ved samme belastning) og <strong>S\u00e6sonudsving<\/strong> (Dags- og ugem\u00f8nstre), s\u00e5 jeg kan skelne mellem reelle \u00e6ndringer og normal adf\u00e6rd.<\/p>\n\n<h2>Placer ScoreboardFile korrekt<\/h2>\n\n<p>P\u00e5 nogle platforme skriver Apache statusdata til en scoreboard-fil, og jeg placerer den i et hurtigt, sikkert bibliotek som f.eks. \/var\/run\/httpd; det \u00f8ger <strong>p\u00e5lidelighed<\/strong>. Jeg forhindrer, at flere instanser bruger den samme fil, da det ellers kan f\u00f8re til forvr\u00e6ngede v\u00e6rdier. Nogle v\u00e6rkt\u00f8jer l\u00e6ser direkte fra filen, hvilket g\u00f8r HTTP-endepunktet overfl\u00f8digt. Det er attraktivt med hensyn til sikkerhed og ydeevne, forudsat at tilladelserne er i orden. Jeg dokumenterer sti og adgang, s\u00e5 vedligeholdelse og <strong>Overv\u00e5gning<\/strong> forblive konsekvent.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/apache-serverauslastung-detail-4893.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>S\u00e6rlige forhold vedr\u00f8rende operativsystemer og containere<\/h2>\n\n<p>Jeg sikrer, at gr\u00e6nserne for filbeskrivere, backlogs og midlertidige stier passer til arbejdsbelastningen. Under systemd kontrollerer jeg, om PrivateTmp eller ReadOnlyPaths p\u00e5virker Scoreboard-stien. I containere planl\u00e6gger jeg lagerpladsbehovet pr. proces\/tr\u00e5d konservativt og placerer Scoreboard-stien i en skrivbar <strong>Runtime-mappe<\/strong>. Til spidsbelastning tilpasser jeg kerneparametrene:<\/p>\n\n<pre><code># Eksempler p\u00e5 sysctl-v\u00e6rdier (test og dokumenter p\u00e5 systemniveau)\nnet.core.somaxconn = 4096\nnet.ipv4.tcp_max_syn_backlog = 4096\nfs.file-max = 1048576\n<\/code><\/pre>\n\n<p>Desuden kalibrerer jeg `ulimit -n` for Apache-tjenesten, s\u00e5 den n\u00e5r op p\u00e5 den maksimale <strong>samtidighed<\/strong> passer (tommelfingerregel: \u00e5bne FD\u2019er \u2248 2\u20133 \u00d7 MaxRequestWorkers i proxy-tunge ops\u00e6tninger). Efter \u00e6ndringer holder jeg \u00f8je med resultattavlen igen for at bekr\u00e6fte effekterne.<\/p>\n\n<h2>Typiske anvendelsestilf\u00e6lde: Identificering af overbelastede medarbejdere<\/h2>\n\n<p>Hvis n\u00e6sten alle slots er optaget med R eller W, og der n\u00e6sten ikke vises _\u2011-poster, k\u00f8rer serveren p\u00e5 sin <strong>Gr\u00e6nse<\/strong>. Derefter tjekker jeg MaxRequestWorkers, responstider og blokerende backends. Hvis flere workers ikke hj\u00e6lper, ligger flaskehalsen ofte i applikationen, databasen eller lagringssystemet. Via \/server-status?auto f\u00f8lger jeg udviklingen i intervaller i stedet for blot at se p\u00e5 \u00f8jebliksbilleder. P\u00e5 den m\u00e5de beslutter jeg, om jeg skal justere indstillingerne, styrke cachen eller <strong>Skalering<\/strong> planl\u00e6gge.<\/p>\n\n<h2>Ressourcemodel og kapacitetsformler<\/h2>\n\n<p>Jeg beregner kapaciteterne p\u00e5 forh\u00e5nd, s\u00e5 jeg undg\u00e5r hukommelsesflaskehalse. For Prefork g\u00e6lder: Hukommelse \u2248 antal processer \u00d7 RSS pr. proces. For Worker\/Event: Hukommelse \u2248 antal processer \u00d7 (RSS pr. proces) + tr\u00e5de \u00d7 tr\u00e5doverhead. Jeg m\u00e5ler den faktiske RSS med systemets v\u00e6rkt\u00f8jer og indregner sikkerhedsmargener. Et lille eksempel: 20 processer \u00d7 50 MB + 500 tr\u00e5de \u00d7 1 MB giver \u2248 1,5 GB, plus cache og OS-buffer. Ud fra dette udleder jeg MaxRequestWorkers, ServerLimit og ThreadsPerChild. Jeg tager desuden h\u00f8jde for, at moduler som SSL, PHP eller reverse-proxying \u00f8ger hukommelsesforbruget pr. <strong>Tr\u00e5d<\/strong> kan \u00f8ge; derfor tester jeg under reel belastning, ikke kun i tomgang.<\/p>\n\n<h2>Fortolke k\u00f8er og ventetid<\/h2>\n\n<p>Hvis foresp\u00f8rgsler forbliver l\u00e6nge i \u00bbAccept\u00ab- eller \u00bbSkriv\u00ab-tilstand, stiger den oplevede ventetid, og jeg ser n\u00e6rmere p\u00e5 k\u00f8ernes l\u00e6ngde samt \u00bbAccept\u00ab-backlog; resultattavlen leverer v\u00e6rdifulde oplysninger herom <strong>Indikatorer<\/strong>. Denne artikel giver mig en mere uddybende forklaring p\u00e5 k\u00f8er, ventetider og behandling af anmodninger: <a href=\"https:\/\/webhosting.de\/da\/webserver-koing-latenstid-handtering-af-anmodninger-serverko\/\">K\u00f8er og ventetid<\/a>. Ud fra disse grundl\u00e6ggende principper vurderer jeg, om flaskehalse opst\u00e5r f\u00f8r, i eller efter Apache. Jeg tolererer korte spidsbelastninger, men l\u00f8ser vedvarende overbelastninger ved at \u00f8ge kapaciteten eller justere arkitekturen. P\u00e5 den m\u00e5de forhindrer jeg, at timeouts eskalerer, og at klienter <strong>afbryde<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/apache_scoreboard_office1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Oprette forbindelse til backend og proxy<\/h2>\n\n<p>I milj\u00f8er med mange proxyer kan jeg ud fra W-faser afg\u00f8re, om workerne er p\u00e5 <strong>Opstr\u00f8ms<\/strong> Vente. ExtendedStatus viser mig VHost og den anmodede ressource; p\u00e5 den m\u00e5de kan jeg sammenholde stier med langsomme backends. Jeg indstiller realistiske timeouts (TimeOut, ProxyTimeout) og kontrollerer forbindelsespooling, s\u00e5 tr\u00e5de ikke blokeres un\u00f8digt. Hvis pipelinen bliver overbelastet ved uploads, regulerer jeg l\u00e6sehastighederne pr. klient og beskytter mig mod langsomme afsendere. Hvis der genereres mange store svar, anvender jeg komprimering, chunking og <strong>Caching<\/strong> overvejes for at forkorte W-tiderne.<\/p>\n\n<h2>Indstil Keep-Alive m\u00e5lrettet<\/h2>\n\n<p>Mange K-poster tyder p\u00e5, at klienter lader forbindelser st\u00e5 \u00e5bne; dette fremskynder efterf\u00f8lgende anmodninger, men kan optage slots <strong>Bind<\/strong>. Jeg indstiller timeouts s\u00e5ledes, at reelle gentagelser drager fordel af dem, uden at inaktivitet blokeres for l\u00e6nge. P\u00e5 meget trafikerede websteder hj\u00e6lper en proxy, der er placeret foran, mig med at samle Keep-Alive-forbindelser effektivt. Til detaljer om finjustering bruger jeg denne vejledning: <a href=\"https:\/\/webhosting.de\/da\/optimal-indstilling-af-apache-keepalive-timeout-med-fokus-pa-ydeevne\/\">Indstilling af Keep-Alive-timeout<\/a>. Med en fornuftig timeout mindskes slot-binding, og serveren forbliver under belastning <strong>lydh\u00f8r<\/strong>.<\/p>\n\n<h2>HTTP\/2, TLS og MPM i samspil<\/h2>\n\n<p>Med HTTP\/2 oplever jeg som regel f\u00e6rre K-bindinger pr. klient, fordi flere str\u00f8mme deler en forbindelse <strong>dele<\/strong>. Event-MPM udnytter her sine styrker: Keep-Alive h\u00e5ndteres mere effektivt, mens det aktive arbejde forbliver forbeholdt tr\u00e5dene. TLS \u00f8ger CPU-forbruget pr. forbindelse; jeg overv\u00e5ger, om h\u00f8je W-andele korrelerer med h\u00f8jt CPU-forbrug, og optimerer krypteringssuiter samt genoptagelse af sessioner. I statusoversigterne kan jeg for hver VHost se, om HTTP\/2- eller TLS-termineringsstier dominerer, og tilpasser kapaciteten i overensstemmelse hermed (f.eks. flere tr\u00e5de i stedet for flere processer, hvis kontekstskift er ressourcekr\u00e6vende).<\/p>\n\n<h2>DNS-opslag og logning under kontrol<\/h2>\n\n<p>Hvis D dukker op flere gange i resultatlisten, tjekker jeg reverse-DNS og aktiverer en lokal cache eller deaktiverer opslag; det s\u00e6nker <strong>Forsinkelse<\/strong>. Hvis jeg ser mange L-poster, bremser logningen behandlingen, s\u00e5 jeg fordeler logfilerne, bruger hurtigere lagring eller asynkrone pipelines. Roterende logfiler konfigurerer jeg s\u00e5ledes, at der ikke opst\u00e5r flush-spidsbelastninger. Samtidig m\u00e5ler jeg skrive-I\/O og fill\u00e5se for at bryde blokerende m\u00f8nstre. P\u00e5 den m\u00e5de vinder jeg bearbejdningstid tilbage og aflaster <strong>Arbejder<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/apache_scoreboard_server_auslastung_4738.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Integration i overv\u00e5gningssystemer<\/h2>\n\n<p>Jeg indsamler periodisk \/server-status?auto, gemmer v\u00e6rdierne som en tidsserie og visualiserer Busy vs. Idle, Req\/s, Bytes\/s og CPU-belastning p\u00e5 <strong>Dashboards<\/strong>. Alarmer definerer t\u00e6rskelv\u00e6rdier for slots, der konstant er fulde, stigende svartider eller us\u00e6dvanlige trafikm\u00f8nstre. Med annoteringer markerer jeg deploymenter, s\u00e5 jeg straks kan se effekterne. Denne historik skelner mellem engangstoppe og reelle tendenser. P\u00e5 den m\u00e5de styrer jeg kapaciteten planm\u00e6ssigt og forhindrer <strong>Overraskelser<\/strong>.<\/p>\n\n<h2>Automatiseret registrering ved hj\u00e6lp af scripts<\/h2>\n\n<p>Til hurtige tjek er et letv\u00e6gts-script, der analyserer Auto-visningen og kun viser de vigtigste tal, nok for mig. Jeg holder foresp\u00f8rgselsintervallerne moderate (f.eks. 10\u201330 sekunder) for at holde overheadet lavt, og jeg m\u00e6rker hver pr\u00f8ve med host, VHost og milj\u00f8.<\/p>\n\n<pre><code>#!\/bin\/sh\nURL=\"http:\/\/127.0.0.1\/server-status?auto\"\ncurl -s \"$URL\" | awk -F': ' '\n  \/BusyWorkers\/ {busy=$2}\n  \/IdleWorkers\/ {idle=$2}\n  \/ReqPerSec\/   {rps=$2}\n  \/BytesPerSec\/ {bps=$2}\n  END { printf(\"busy=%s idle=%s rps=%.2f bps=%.0f\\n\", busy, idle, rps, bps) }\n'\n<\/code><\/pre>\n\n<p>I st\u00f8rre milj\u00f8er aggregerer jeg desuden tiderne pr. worker, tildeler dem til VHosts og beregner <strong>Kvantil<\/strong> for responstider. P\u00e5 den m\u00e5de kan jeg se, om det kun er en del af brugerne, der oplever problemer, eller om flertallet er ber\u00f8rt.<\/p>\n\n<h2>MPM og kapacitetsplanl\u00e6gning<\/h2>\n\n<p>MPM fastl\u00e6gger, hvordan Apache behandler forbindelser; Scoreboard-data viser mig, om det er processer eller tr\u00e5de, der udg\u00f8r den begr\u00e6nsende faktor <strong>Faktor<\/strong> er. Til udv\u00e6lgelsen og finjusteringen sammenligner jeg event og worker, m\u00e5ler inaktivitetstider, keep-alive-binding og kontekstskift. Denne artikel giver en kortfattet sammenligning: <a href=\"https:\/\/webhosting.de\/da\/apache-event-mpm-vs-worker-mpm-finjustering-og-optimering-af-webserveren\/\">Begivenhed vs. medarbejder MPM<\/a>. Efter \u00e6ndringer tjekker jeg igen Busy\/Idle og Req\/s for at dokumentere effekterne. P\u00e5 den m\u00e5de tr\u00e6ffer jeg datadrevne beslutninger og \u00f8ger <strong>Effektivitet<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/serverraum-apache-5542.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Graceful Restart, rullende implementeringer og vedligeholdelse<\/h2>\n\n<p>Ved implementeringer eller konfigurations\u00e6ndringer foretr\u00e6kker jeg at udl\u00f8se en <strong>yndefuld<\/strong> Genstart afbrudt. I Scoreboard kan jeg se det p\u00e5 de mange G-tilstande, mens nye processer starter, og gamle afsluttes ordentligt. Jeg planl\u00e6gger rullende \u00e6ndringer, s\u00e5 der er tilstr\u00e6kkelig ledig kapacitet tilbage: f\u00f8rst reducerer jeg belastningen, derefter genstarter jeg graceful, og til sidst de resterende noder. Langvarige G-faser er et tegn p\u00e5, at gamle processer venter p\u00e5 langsomme anmodninger \u2013 s\u00e5 tjekker jeg timeouts og keep-alive for at forkorte omskiftningstiden.<\/p>\n\n<h2>Trin for trin mod en velunderbygget analyse<\/h2>\n\n<p>Jeg aktiverer mod_status, sikrer adgangen og sl\u00e5r ExtendedStatus til, s\u00e5 jeg kan se alle <strong>Detaljer<\/strong> f\u00e5r. Derefter tjekker jeg HTML-siden i browseren og l\u00e6rer symbolernes m\u00f8nster i live-drift at kende. I n\u00e6ste trin integrerer jeg \/server-status?auto i min overv\u00e5gning og validerer m\u00e5lingerne. Derefter optimerer jeg f\u00f8lgende punkter \u00e9n efter \u00e9n: antal arbejdere, keep-alive, timeouts, caching og applikationsstier. Jeg m\u00e5ler hver \u00e6ndring p\u00e5 ny, indtil Req\/s, responstid og Busy\/Idle igen ligger inden for <strong>Gr\u00f8nt omr\u00e5de<\/strong> l\u00f8gn.<\/p>\n\n<h2>Resum\u00e9: Apache Scoreboard som kompas<\/h2>\n\n<p>Apache Scoreboard giver mig et klart og umiddelbart anvendeligt overblik over udnyttelsesgraden, flaskehalse og adf\u00e6rden hos <strong>Arbejder<\/strong>. Med mod_status, ExtendedStatus og grundig overv\u00e5gning omdanner jeg r\u00e5data til p\u00e5lidelige beslutninger. Indikatorer og m\u00e5linger viser, om jeg skal udvide kapaciteten, justere timeout-tiderne eller tage fat p\u00e5 selve applikationen. En lille \u00e6ndring af Keep-Alive eller MPM kan have stor effekt, hvis dataene er korrekte. Den, der tolker tegnene rigtigt, holder Apache k\u00f8rende under belastning <strong>lydh\u00f8r<\/strong> og planl\u00e6gbar.<\/p>","protected":false},"excerpt":{"rendered":"<p>Find ud af, hvordan Apache Scoreboard kan hj\u00e6lpe dig med at analysere webserveren: L\u00e6r, hvordan du konfigurerer mod_status, fortolker Scoreboard-ikonerne og bruger Apache-overv\u00e5gning til at optimere serverudnyttelsen.<\/p>","protected":false},"author":1,"featured_media":21484,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[834],"tags":[],"class_list":["post-21491","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-plesk-webserver-plesk-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"105","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"Apache Scoreboard","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"21484","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/21491","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/comments?post=21491"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/21491\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media\/21484"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media?parent=21491"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/categories?post=21491"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/tags?post=21491"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}