Table of Contents
Questa sezione copre una varietà di argomenti legati al tuning delle prestazioni. Si cercherà di percorrere le tecniche di tuning da una prospettiva dell'amministratore di sistema ai programmatori di sistema. L'arte del tuning delle performance in sè è molto vecchio. Fare il tuning di qualcosa significa fare in modo che questa operi più efficientemente, che ci si riferisca a un server tecnico basato su NetBSD o ad un aspirapolvere, l'obiettivo è di migliorare qualcosa, in che modo questo sia fatto, come funziona o come fanno tutti i pezzi a stare insieme.
Una vista da 10.000 piedi mostra molto chiaramente che tutto ciò che facciamo è orientato al lavoro, questo in egual modo si addice al sistema NetBSD. Quando il sistema si avvia comincia automaticamente ad effettuare una varietà di lavori. Quando un utente accede al sistema (effettua il login, NdT), generalmente ha una varietà di mansioni che deve svolgere. Come scopo di questi documenti, tuttavia, tuning delle prestazioni significa migliorare l'efficienza con la quale un sistema NetBSD gira.
Il pensiero più comune che balza nella testa di qualcuno quando pensa al "tuning" è qualche sorta di incremento della velocità o decremento della dimensione del kernel - mentre questi sono modi per migliorare le prestazioni, non sono solo i soli fini che un amministratore potrebbe dovrer prendere per incrementare l'efficienza. Per i nostri scopi, il tuning delle prestazioni significa questo: Rendere un sistema NetBSD in condizioni di operare in un ottimo stato.
Il quale potrebbe significare una varietà di cose, non necessariamente il miglioramento della velocità. Un buon esempio di questo sono i parametri di formattazione del file system, in un sistema che ha un sacco di piccoli file (come in un repository di sorgenti) un amministratore potrebbe aver bisogno di incrementare il numero di inode rendendo la loro dimensione più piccola (qualcosa al di sotto dei 1024k) e quindi incrementare l'ammontare degli inode. In questo caso il numero di inode è stato incrementato, tuttavia, consente all'amministratore di lasciare fuori questi fastidiosi messaggi di inode, cosa che infine rende il sistema più efficiente.
Il tuning normalmente gira intorno a ricerca ed eleminazione di ingorghi. Gran parte del tempo, questi ingorghi sono sporchi, per esempio, un rilascio di Mozzilla che non gestisce correttamente le applet java può causare con molta facilita che Mozzilla si avvii mangiando la CPU, specialmente con delle applet che non sono fatte bene. Le occasioni in cui i processi sembrano non fare niente e mangiano CPU sono quasi sempre risolte con un kill. Ci sono situazioni, tuttavia, che la risoluzione di ingorghi richiede molto più tempo, per esempio, un server rsync andrà solo ad ingrandire. Lentamente, le prestazioni cominciano a diminuire e l'amministratore deve intraprendere una qualche tipo di azione per accellerare le cose, tuttavia, la situazione è relativa ad un'emergenza come il blocco istantaneo della CPU.
Molti utenti NetBSD raramente devono fare tuning su un sistema. Il kernel GENERIC può girare tranquillamente e il layout o la configurazione di sistema possono fare ugualmente il loro lavoro. Allo stesso modo, come un pragma è sempre bene sapere come fare tuning su un sistema. Molto spesso il tuning proviene come risultato di un'improvvisa situazione di ingorgo (il quale può verificarsi casualmente) o una graduale perdita di prestazioni. Questo succede in un senso che ognuno a questo punto, un processo che stà mangiando la CPU è un ingorgo tanto quanto un graduale incremento in pagin. Quindi, la questione importante non dovrebbe essere quando fare tuning ma quando imparare a fare tuning.
Un'ultima volta per fare tuning è se puoi farlo in modo preventivo (e pensi di averne bisogno) allora fallo. Un esempio di questo fu in un sistema che necessitava di essere riavviato rapidamente. Invece di attendere, ho fatto tutto il possibile per alleggerire il kernel e assicurarmi che non ci fosse in esecuzione niente che non fosse necessario, ho anche rimosso driver necessari per le periferiche, ma che non avevo mai usato (lp). Il risultato produsse un tempo di riavvio due-tre volte più rapido. A lungo andare, quella fu una mossa astuta fare il tuning prima che si verificasse il problema.
Prima di concludere l'introduzione, credo che sia importante far notare cosa questi documenti non trattano. Questa guida sarà pertinente solo al nucleo (il cosiddetto core, NdT) del sistema NetBSD. In altre parole, non coprirà il tuning della configurazione di un server web. La logica che stà dietro ciò è semplice: i server web, i software per database, etc. sono di terze parti e quasi privi di limiti. I potrei facilmente scendere in dettagli che vanno al di là del sistema NetBSD. Quasi tutti i software di terze parti hanno le loro documentazioni su come fare tuning, comunque.
Dal momento che c'è un'ampia documentazione di pagine di manuale, saranno discusse solo le opzioni e gli argomenti usati con gli esempi. In alcuni casi, il materiale sarà troncato per brevità e non approfonditamente discusso perchè, banalmente, c'è troppo da dire. Per esempio, ogni singola voce di un driver di periferica nel kernel non sarà diuscussa, tuttavia, lo sarà un esempio che determini cosa serva per un dato sistema. Niente in questa guida è concreto, il tuning e le prestazioni sono molto soggettive, invece, questa è una guida per insegnare al lettore cosa possono fare alcuni degli strumenti a sua disposizione.
Il tuning di un sistema non è realmente troppo difficoltoso quando l'approccio è il tuning pro-attivo. Questo documento approccia al tuning da un approccio “prima che si verifichi”. Mentre fare tuning a tempo perso è considerevolmente più facile rispetto a un server che è quasi completamente impantanato allo 0.1% di idle time (tempo di risposta, NdT), ci sono ancora un pò di cose che adrebbero fatte riguardo al tuning prima di farlo praticamente, ci si augura, anche prima che il sistema sia installato.
Naturalmente, il modo in cui il sistema è stato messo a punto fa una grande differenza. Ogni tanto piccole cose possono sfuggire il che infatti causa a lungo termine qualche tipo di problemi di prestazioni.
Come si presenta il file system sulle periferiche a disco
è molto importante. In sistemi di RAID hardware, non
è un grosso affare, ma, molti utenti NetBSD usano in
modo specifico NetBSD su vecchio hardware dove il RAID
hardware semplicemente non è un'opzione. L'idea di
associare / al primo disco è buona,
ma per esempio se ci sono diversi dischi dai quali scegliere
quale sarà il primo, quello su cui andrà
/ sarà la scelta migliore? Su
una nota relativa, è saggio avere la
/usr separata? Il sistema avrà un
grosso carico in directory come /usr/pkgsrc?
Avrebbe senso piazzare un disco rapido e montarlo sotto
/usr/pkgsrc, o non ne avrebbe. Come tutte
le cose nel tuning delle prestazioni, questo è soggettivo.
Ci sono tre scuole di pensiero sulla dimensione della swap e circa quindici riguardo a usare piccoli file come swap con delle priorità su e come queste dovrebbero essere fatte. Nell'arena della dimensione della swap, la scuola dei fornitori (almeno quella più commerciale) usualmente hanno le loro formule per sistema operativo. Come esempio, in una particolare versione di HP-UX con una particolare versione di Oracle la formula era:
2.5 GB * Numero_di_processori
Bene, tutto questo veramente dipende da quale tipo di uso si fa del database o quanto questo sia largo, per la cronaca, se è cosi largo da dover essere distribuito, quella formula non soddisfa affatto.
La prossima scuola di pensiero riguardo alla dimensione della swap è un tipo strano ma sensato, che sostiene, se possibile, prendi come riferimento una quantità di memoria utilizzata dal sistema. Sarebbe qualcosa tipo questa:
Accendi la macchina e calcola il tempo totale che la memoria richiede per eseguire qualsiasi cosa che possa essere immediatamente richiesta. Database, server web, altro. Fai il totale della quantità.
Aggiungi qualche MB per riempimento.
Sottrai l'ammontare della RAM fisica da questo totale.
Se l'ammontare rimanente è 3 volte la dimensione della RAM fisica, considera la possibilità di aggiungere più RAM. Il problema, naturalmente, è trovare cosa serve e quanto spazio prenderà. C'è anche un'altra carenza in questo metodo, qualche programma non si comporta bene. Un brillante esempio di malfunzionamento software è sono i browser web. Una certa versione di Netscape, quando qualcosa è andato storto ha la tendenza a diventare instabile e mangiare spazio di swap. Così, più c'è spazio disponibile, più c'è tempo per killarlo.
Ultimo non per importanza è il metodo prova e allinea la RAM_FISICA * 2. Su macchine moderne e anche su quelle vecchie (con utilizzi limitati, naturalmente) questo sembra funzionare in modo migliore.
Tutto per tutto, è difficile da dire quando comincerà lo swapping. Anche su piccole macchine con 16MB di RAM (o meno) NetBSD ha sempre funzionato bene per molta gente fino all'esecuzione di software difettosi.
Sui server, i servizi di sistema hanno un grande impatto. Ottenendoli per eseguirli al loro meglio quasi sembre richiede qualche tipo di cambiamento a livello di rete o un fondamentale incremento di velocità nel sistema sottostante (il quale naturalmente è tutto ciò che ci riguarda). Ci sono circostanze in cui alcune semplici soluzioni possono migliorare i servizi. Un esempio, un server ftp diventa più lento e viene rilasciata una nuova versione del server ftp che esce con il sistema, banalmente questo girerà più rapidamente. Aggiornando il software ftp, si verifica una spinta nelle prestazioni.
Un altro buon esempio che concerne i servizi è la vecchia domanda: “Usare o meno inetd?” Un grande servizio d'esempio è pop3. Le connessioni pop3 in teoria possono bloccare inid. Mentre il servizio pop3 stesso comincia a degradare lentamente, altri servizi che sono in multiplex attraverso inetd degraderanno pure (in alcuni casi più di pop3). Facendo in modo che pop3 giri al di fuori di inetd e per conto suo può aiutare.
Il kernel NetBSD ovviamente gioca un ruolo chiave su come un sistema sia prestante, mentre ricompilare e fare il tuning del kernel è trattato nel successivo testo, è di rilievo discutere sul contesto locale da un alto livello.
Il tuning sul kernel NetBSD in realtà coinvolge tre aree principali
rimuovere i driver non necessari
configurare le opzioni
impostazioni di sistema
Togliendo dal kervel i driver che non sono necessari si raggiungono diversi risultati; primo, il sistema si avvia più velocemente dal momento che il kernel è più piccolo, secondo di nuovo visto che il kernel è più piccolo, c'è più memoria libera per gli utenti e i processi, e terzo, il kernel tende a rispondere più rapidamente.
Configurare le opzioni come abilitare/disabilitare certi sottosistemi, hardware e file system specifici può anche migliorare molto le prestazioni allo stesso modo di rimuovere i driver non necessari. Un esempio molto semplice di ciò è un server FTP che ospita solo file ftp - nient'altro. Su questo particolare server non c'è bisogno di avere ogni cosa eccetto il supporto nativo per il file system e forse poche opzioni per aiutare ad accellerare un pò le cose. Perché dovrebbe richiedere il supporto NTFS per esempio? Da un lato, se così fosse, il supporto NTFS potrebbe essere aggiunto in qualche successivo momento. Nel caso opposto, una stazione di lavoro potrebbe aver bisogno di supportare parecchi altri tipi differenti di file system per condividere e accedere ai file.
Le impostazioni del sistema su larga scala sono controllate dal kernel, qualche esempio sono la configurazione dei file system, impostazioni di rete configurazione base del kernel come il numero massimo di processi. Quasi tutte le configurazioni di sistema possono essere almeno lette o modificate attraverso la funzioni sysctl. Esempi che utilizzano la funzione sysctl sono esposti in seguito.
NetBSD offre una varietà di strumenti di monitoraggio per le prestazioni col sistema. Molti di questi strumenti sono comuni su tutti i sistemi UNIX. In questa sezione si mostrerà qualche esempio di uso degli strumenti con l'interpretazione dell'output.
Il monitor top fa esattamente quanto detto: mostra il carico della CPU nel sistema. Per eseguire il monitor, scrivere semplicemente top sul prompt. Senza alcuna rgomento, apparirà in questo modo:
load averages: 0.09, 0.12, 0.08 20:23:41
21 processes: 20 sleeping, 1 on processor
CPU states: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle
Memory: 15M Act, 1104K Inact, 208K Wired, 22M Free, 129M Swap free
PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND
13663 root 2 0 1552K 1836K sleep 0:08 0.00% 0.00% httpd
127 root 10 0 129M 4464K sleep 0:01 0.00% 0.00% mount_mfs
22591 root 2 0 388K 1156K sleep 0:01 0.00% 0.00% sshd
108 root 2 0 132K 472K sleep 0:01 0.00% 0.00% syslogd
22597 jrf 28 0 156K 616K onproc 0:00 0.00% 0.00% top
22592 jrf 18 0 828K 1128K sleep 0:00 0.00% 0.00% tcsh
203 root 10 0 220K 424K sleep 0:00 0.00% 0.00% cron
1 root 10 0 312K 192K sleep 0:00 0.00% 0.00% init
205 root 3 0 48K 432K sleep 0:00 0.00% 0.00% getty
206 root 3 0 48K 424K sleep 0:00 0.00% 0.00% getty
208 root 3 0 48K 424K sleep 0:00 0.00% 0.00% getty
207 root 3 0 48K 424K sleep 0:00 0.00% 0.00% getty
13667 nobody 2 0 1660K 1508K sleep 0:00 0.00% 0.00% httpd
9926 root 2 0 336K 588K sleep 0:00 0.00% 0.00% sshd
200 root 2 0 76K 456K sleep 0:00 0.00% 0.00% inetd
182 root 2 0 92K 436K sleep 0:00 0.00% 0.00% portsentry
180 root 2 0 92K 436K sleep 0:00 0.00% 0.00% portsentry
13666 nobody -4 0 1600K 1260K sleep 0:00 0.00% 0.00% httpd
Il programma di utilità top è grande per trovare problemi della CPU, instabilità dei processi o gruppi di processi che possono causare problemi. L'output mostrato sopra indica che questo particolare sistema è in buono stato. Ora, la prossima schermata dovrebbe mostrare qualche risultato molto differente:
load averages: 0.34, 0.16, 0.13 21:13:47
25 processes: 24 sleeping, 1 on processor
CPU states: 0.5% user, 0.0% nice, 9.0% system, 1.0% interrupt, 89.6% idle
Memory: 20M Act, 1712K Inact, 240K Wired, 30M Free, 129M Swap free
PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND
5304 jrf -5 0 56K 336K sleep 0:04 66.07% 19.53% bonnie
5294 root 2 0 412K 1176K sleep 0:02 1.01% 0.93% sshd
108 root 2 0 132K 472K sleep 1:23 0.00% 0.00% syslogd
187 root 2 0 1552K 1824K sleep 0:07 0.00% 0.00% httpd
5288 root 2 0 412K 1176K sleep 0:02 0.00% 0.00% sshd
5302 jrf 28 0 160K 620K onproc 0:00 0.00% 0.00% top
5295 jrf 18 0 828K 1116K sleep 0:00 0.00% 0.00% tcsh
5289 jrf 18 0 828K 1112K sleep 0:00 0.00% 0.00% tcsh
127 root 10 0 129M 8388K sleep 0:00 0.00% 0.00% mount_mfs
204 root 10 0 220K 424K sleep 0:00 0.00% 0.00% cron
1 root 10 0 312K 192K sleep 0:00 0.00% 0.00% init
208 root 3 0 48K 432K sleep 0:00 0.00% 0.00% getty
210 root 3 0 48K 424K sleep 0:00 0.00% 0.00% getty
209 root 3 0 48K 424K sleep 0:00 0.00% 0.00% getty
211 root 3 0 48K 424K sleep 0:00 0.00% 0.00% getty
217 nobody 2 0 1616K 1272K sleep 0:00 0.00% 0.00% httpd
184 root 2 0 336K 580K sleep 0:00 0.00% 0.00% sshd
201 root 2 0 76K 456K sleep 0:00 0.00% 0.00% inetd
Innanzi tutto, dovrebbe sembrare piuttosto ovvio quale processo stà sovracaricando il sistema, tuttavia, la cosa interessante in questo caso è il perché. Il programma bonnie è uno strumento per il benchmark che può scrivere grandi file in una varieta di dimensioni e modi. Il precedente output ha indicato solo che il programma bonnie stà caricando la CPU, ma non il perché.
Un'accurato esame della pagina di manuale top(1) mostra che c'è molto più che può essere fatto con top, per esempio, i processi possono avere la loro priorità cambiata e possono essere killati. In aggiunta, possono essere impostati dei filtri per la visualizzazione dei processi.
Come indica la pagina di manuale sysstat(1), il programma di utilità sysstat mostra una varietà di statistiche di sistema usando le librerie curses. Mentre è in esecuzione lo schermo è diviso in due parti, la finestra di sopra mostra il carico medio corrente mentre la parte più bassa dello schermo dipende dai comandi dell'utente. L'eccezione alla vista con le finestre divise è quando si visualizza vmstat il quale prende l'intero schermo. Quanto segue è come appare sysstat quando è invocato senza argomenti su un sistema ragionevolmente reattivo:
/0 /1 /2 /3 /4 /5 /6 /7 /8 /9 /10
Load Average |
/0 /10 /20 /30 /40 /50 /60 /70 /80 /90 /100
<idle> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Praticamente c'è un sacco di tempo morto, così adesso diamo un'occhiata fornendo qualche argomento, in questo caso, sysstat inet.tcp che appare come questo:
/0 /1 /2 /3 /4 /5 /6 /7 /8 /9 /10
Load Average |
0 connections initiated 19 total TCP packets sent
0 connections accepted 11 data
0 connections established 0 data (retransmit)
8 ack-only
0 connections dropped 0 window probes
0 in embryonic state 0 window updates
0 on retransmit timeout 0 urgent data only
0 by keepalive 0 control
0 by persist
29 total TCP packets received
11 potential rtt updates 17 in sequence
11 successful rtt updates 0 completely duplicate
9 delayed acks sent 0 with some duplicate data
0 retransmit timeouts 4 out of order
0 persist timeouts 0 duplicate acks
0 keepalive probes 11 acks
0 keepalive timeouts 0 window probes
0 window updates
Ora è informativo. Il primo risultato è cumulativo, così è possibile vedere tranquillamente un sacco di informazioni nell'output quando sysstat viene invocato. Ora, ciò può essere interessante, più o meno come dare un'occhiata alla cache del buffer con sysstat bufcache:
/0 /1 /2 /3 /4 /5 /6 /7 /8 /9 /10
Load Average
There are 1642 buffers using 6568 kBytes of memory.
File System Bufs used % kB in use % Bufsize kB % Util %
/ 877 53 6171 93 6516 99 94
/var/tmp 5 0 17 0 28 0 60
Total: 882 53 6188 94 6544 99
Di nuovo, un sistema piuttosto noioso, ma con tantissime informazioni disponibili. Mentre tutto questo è piacevole da vedere, è il momento di aggiungere mettere qualche falso carico al sistema per vedere come sysstat può essere usato come strumento di controllo delle prestazioni. Come con top, bonnie++ sarà usato per aggiungere un alto carico al sottosistema I/O e anche un pò sulla CPU. Si guarderà nuovamente alla bufcache per vedere le differenze rilevanti:
/0 /1 /2 /3 /4 /5 /6 /7 /8 /9 /10
Load Average |||
There are 1642 buffers using 6568 kBytes of memory.
File System Bufs used % kB in use % Bufsize kB % Util %
/ 811 49 6422 97 6444 98 99
Total: 811 49 6422 97 6444 98
Primo, notare che il carico medio è drasticamente salito, questo naturalmente c'era da aspettarselo, allora, mentre la maggior parte dei numeri sono fissi, notare che l'utilizzo è al 99% DUrante il tempo d'esecuzione di bonnie++ la percentuale di utilizzo rimane al 99%, questo naturalmente ha un senso, tuttavia, in una vera situazione di dubbio e incertezza, potrebbe essere indicativo un processo che stà caricando l'I/O su un particolare file o file system.
In aggiunta agli strumenti di monitoraggio orientati allo schermo, il sistema NetBSD esce con un insieme di strumenti orientati alla riga di comando. Molti degli strumenti che escono con un sistema NetBSD possono essere trovati in altri sistemi UNIX e UNIX-like.
Il programma di utilità fstat(1) riporta lo stato dei file aperti nel sistema, mentre non è quello che molti amministratori considerano un monitor per le prestazioni, può aiutare a trovare se un particolare utente o processo sta usando un disordinato ammontare di file, generando grandi file e informazioni simili.
Il seguente è un esempio di qualche output di fstat:
USER CMD PID FD MOUNT INUM MODE SZ|DV R/W jrf tcsh 21607 wd / 29772 drwxr-xr-x 512 r jrf tcsh 21607 3* unix stream c057acc0<-> c0553280 jrf tcsh 21607 4* unix stream c0553280 <-> c057acc0 root sshd 21597 wd / 2 drwxr-xr-x 512 r root sshd 21597 0 / 11921 crw-rw-rw- null rw nobody httpd 5032 wd / 2 drwxr-xr-x 512 r nobody httpd 5032 0 / 11921 crw-rw-rw- null r nobody httpd 5032 1 / 11921 crw-rw-rw- null w nobody httpd 5032 2 / 15890 -rw-r--r-- 353533 rw ...
Le voci sono abbastanza auto esplicativo, ancora, questo strumento mentre non è orientato alle prestazioni come gli altri, può tornare utile quando si cercano informazioni riguardo all'utilizzo dei file.
Il comando iostat(8) fa esattamente quello che sembra, riporta lo stato dei sottosistemi I/O nel sistema. Quando iostat è impiegato, l'utente tipicamente lo esegue con un certo numero di conteggi e un intervalo fra loro tipo:
$iostat 5 5tty wd0 cd0 fd0 md0 cpu tin tout KB/t t/s MB/s KB/t t/s MB/s KB/t t/s MB/s KB/t t/s MB/s us ni sy in id 0 1 5.13 1 0.00 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0 0 0 0 100 0 54 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0 0 0 0 100 0 18 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0 0 0 0 100 0 18 8.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0 0 0 0 100 0 28 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0 0 0 0 100
L'output di sopra proviene da un server ftp molto tranquillo. Le voci rappresentano le varie periferiche di I/O, il tty (il quale, ironicamente, è il più attivo perchè iostat è in esecuzione), wd0 che è il disco IDE primario, cd0, il lettore cdrom, fd0, il floppy e il memory file system.
Ora, vediamo se è possibile inchiodare il sistema con qualche pesante carico di utilizzo. Primo, una grossa transazione ftp consistente di un tarball coi sorgenti di netbsd-current con il programma per il benchmark del disco bonnie++ in esecuzione allo stesso tempo.
$iostat 5 5tty wd0 cd0 fd0 md0 cpu tin tout KB/t t/s MB/s KB/t t/s MB/s KB/t t/s MB/s KB/t t/s MB/s us ni sy in id 0 1 5.68 1 0.00 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0 0 0 0 100 0 54 61.03 150 8.92 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 1 0 18 4 78 0 26 63.14 157 9.71 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 1 0 20 4 75 0 20 43.58 26 1.12 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0 0 9 2 88 0 28 19.49 82 1.55 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 1 0 7 3 89
Come ci si può aspettare, si nota che wd0 è molto attivo, la cosa interessante di questo output è quanto l'I/O del processore sembra aumentare in proporzione a wd0. Questo ha perfettamente senso, tuttavia, vale la pena notare che questo può essere osservato solo perchè il server ftp può difficilmente venire usato. Se, per esempio, il sottosistema I/O della CPU fosse già sotto un moderato carico e il sottosistema disco fosse sotto lo stesos carico di adesso, potrebbe apparire che la CPU sia intasata quando infatti sarebbe stato il disco. In questo caso, è possibile osservare che "un tool" è raramente abbastanza per analizzare completamente un problema. Una rapida occhiata ai processi probabilmente potrà dirci (dopo aver guardato iostat) quali processi stanno causando problemi.
Usando il comando ps(1) o process status, possono essere scoperte una grande quantità di informazioni sul sistema. Buona parte del tempo, il comando ps è usato per isolare un processo particolare per nome, gruppo, proprietario, etc. Invocato senza nè opzioni nè argomenti, ps stampa semplicemente informazioni riguardanti l'utente che lo stà eseguendo.
$psPID TT STAT TIME COMMAND 21560 p0 Is 0:00.04 -tcsh 21564 p0 I+ 0:00.37 ssh jrf.odpn.net 21598 p1 Ss 0:00.12 -tcsh 21673 p1 R+ 0:00.00 ps 21638 p2 Is+ 0:00.06 -tcsh
Non molto eccitante. Le voci sono auto esplicative con l'eccezione di STAT che è lo stato attuale in cui si trova un processo. Le flag sono tutte documentate nella pagina di manuale, tuttavia, nell'esempio precedente, I stà per idle, S per sleeping, R per runnable, il + significae che il processo è in uno stato di foreground, e la s significa che il processo è un leader di sessione. Tutto questo ha perfettamente un senso quando guardando alle flag, per esempio, PID 21560 è la shell, è nello stato di idle e (come ci si può aspettare) la shell è un leader di sessione.
In molti casi, qualcuno potrebbe cercare qualcosa di molto specifico nella lista dei processi. Ad esempio, la vista di tutti i processi si specifica con -a, per vedere tutti i processi più quelli senza terminale di controllo si usa -ax e per ottenere una lista molto più dettagliata (di norma tutto più informazioni sull'impatto che hanno i processi) aux:
#ps auxUSER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND root 0 0.0 9.6 0 6260 ?? DLs 16Jul02 0:01.00 (swapper) root 23362 0.0 0.8 144 488 ?? S 12:38PM 0:00.01 ftpd -l root 23328 0.0 0.4 428 280 p1 S 12:34PM 0:00.04 -csh jrf 23312 0.0 1.8 828 1132 p1 Is 12:32PM 0:00.06 -tcsh root 23311 0.0 1.8 388 1156 ?? S 12:32PM 0:01.60 sshd: jrf@ttyp1 jrf 21951 0.0 1.7 244 1124 p0 S+ 4:22PM 0:02.90 ssh jrf.odpn.net jrf 21947 0.0 1.7 828 1128 p0 Is 4:21PM 0:00.04 -tcsh root 21946 0.0 1.8 388 1156 ?? S 4:21PM 0:04.94 sshd: jrf@ttyp0 nobody 5032 0.0 2.0 1616 1300 ?? I 19Jul02 0:00.02 /usr/pkg/sbin/httpd ...
Di nuovo, molte delle voci sono auto esplicative con l'eccezione di VSZ e RSS le quali possono essere un pò confusionarie. RSS è la dimensione reale del processo in unità da 1024 byte mentre VSZ è la dimensione virtuale. Tutto questo è grandioso, ma ancora, come può aiutare ps? Bene, intanto, si dia un'occhiata a questa versione modificata dell'output:
#ps auxUSER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND root 0 0.0 9.6 0 6260 ?? DLs 16Jul02 0:01.00 (swapper) root 23362 0.0 0.8 144 488 ?? S 12:38PM 0:00.01 ftpd -l root 23328 0.0 0.4 428 280 p1 S 12:34PM 0:00.04 -csh jrf 23312 0.0 1.8 828 1132 p1 Is 12:32PM 0:00.06 -tcsh root 23311 0.0 1.8 388 1156 ?? S 12:32PM 0:01.60 sshd: jrf@ttyp1 jrf 21951 0.0 1.7 244 1124 p0 S+ 4:22PM 0:02.90 ssh jrf.odpn.net jrf 21947 0.0 1.7 828 1128 p0 Is 4:21PM 0:00.04 -tcsh root 21946 0.0 1.8 388 1156 ?? S 4:21PM 0:04.94 sshd: jrf@ttyp0 nobody 5032 9.0 2.0 1616 1300 ?? I 19Jul02 0:00.02 /usr/pkg/sbin/httpd ...
Dato quello su questo server, la nostra linea di base indica un sistema relativamente apposto, il PID 5032 ha un insolito largo ammontare di %CPU. Qualche volta questo può anche causare un alto numero per TIME. Il comando ps può essere greppato per PID, username e nome del processe e quindi può aiutare a tracciare i processi che possono provocare problemi.
Usando vmstat(1), possono essere monitorate e misurate le informazioni pertinenti alla memoria virtuale. Non diversamente da iostat, vmstat può essere invocato con un dei conteggi è un intervallo. Il seguente è qualche esempio di output usando 5 5 come nell'esempio di iostat:
#vmstat 5 5procs memory page disks faults cpu r b w avm fre flt re pi po fr sr w0 c0 f0 m0 in sy cs us sy id 0 7 0 17716 33160 2 0 0 0 0 0 1 0 0 0 105 15 4 0 0 100 0 7 0 17724 33156 2 0 0 0 0 0 1 0 0 0 109 6 3 0 0 100 0 7 0 17724 33156 1 0 0 0 0 0 1 0 0 0 105 6 3 0 0 100 0 7 0 17724 33156 1 0 0 0 0 0 0 0 0 0 107 6 3 0 0 100 0 7 0 17724 33156 1 0 0 0 0 0 0 0 0 0 105 6 3 0 0 100
Ancora una volta, relativamente apposto, per coincidenza, su questo server è stato messo lo stesso identico carico usato nell'esempio di iostat. Il carico è il trasferimento di un grande file e del programma per i benchmark, bonnie.
#vmstat 5 5procs memory page disks faults cpu r b w avm fre flt re pi po fr sr w0 c0 f0 m0 in sy cs us sy id 1 8 0 18880 31968 2 0 0 0 0 0 1 0 0 0 105 15 4 0 0 100 0 8 0 18888 31964 2 0 0 0 0 0 130 0 0 0 1804 5539 1094 31 22 47 1 7 0 18888 31964 1 0 0 0 0 0 130 0 0 0 1802 5500 1060 36 16 49 1 8 0 18888 31964 1 0 0 0 0 0 160 0 0 0 1849 5905 1107 21 22 57 1 7 0 18888 31964 1 0 0 0 0 0 175 0 0 0 1893 6167 1082 1 25 75
Solo una piccola differenza. Da notare che dal momento che gran
parte del lavoro è basato sull'I/O, l'attuale memoria
utilizzata non è molta. Visto che questo sistema usa mfs
per /tmp, tuttavia, può certamente
peggiorare. Diamo un'occhiata a questo:
#vmstat 5 5procs memory page disks faults cpu r b w avm fre flt re pi po fr sr w0 c0 f0 m0 in sy cs us sy id 0 2 0 99188 500 2 0 0 0 0 0 1 0 0 0 105 16 4 0 0 100 0 2 0111596 436 592 0 587 624 586 1210 624 0 0 0 741 883 1088 0 11 89 0 3 0123976 784 666 0 662 643 683 1326 702 0 0 0 828 993 1237 0 12 88 0 2 0134692 1236 581 0 571 563 595 1158 599 0 0 0 722 863 1066 0 9 90 2 0 0142860 912 433 0 406 403 405 808 429 0 0 0 552 602 768 0 7 93
Abbastanza spaventoso. Questo è stato create per eseguire
bonnie su /tmp in un file system basato sulla
memoria. Se si continua per troppo tempo, è possibile che il
sistema cominci a creare immondizia. Notare che anche se il sottosistema
della VM stia peggiorando, i processori non stanno ancora andando in
avaria.
Qualche volta un problema di prestazioni non è una macchina in particolare, è la rete o qualche tipo di periferica nella rete come un altro host, un router, etc. Cosa fanno le altre macchine che forniscono un servizio o un qualche tipo di connettività su un particalare sistema NetBSD e come queste agiscono può avere un impatto molto forte sulle prestazioni del sistema NetBSD stesso, e sulla percezione delle prestazioni da parte degli utenti. Un esempio realmente grandioso di questo è quando un server DNS una macchina NetBSD stà utilizzando improvvisamente sparisce. Le risoluzioni prendono tempi molto lunghi ed eventualmente falliscono. Qualcuno con poca esperienza loggato nella macchina NetBSD potrebbe indubbiamente (in quanto ci sono altre prove) incolpare il sistema NetBSD. Uno dei miei preferiti personali, “the Internet is broke”, generalmente significa che il servizio DNS o il route/gateway ha interrotto la connessione. Qualunque sia il caso, un sistema NetBSD viene adeguatamente munito per avere a che fare con la scoperta di quali guasti di rete stanno causando problemi, se la causa è del sistema locale o qualcos'altro.
Il classico programma di utilità ping(8) può dirci
se cèè semplicemente una connettività normale,
può anche dirci se la risoluzione dell'host (dipendentemente
da come indica nsswitch.conf) funziona. Quanto
segue è un tipico output di ping su una rete locale con un
conteggio di 3 specificato:
#ping -c 3 mariePING marie (172.16.14.12): 56 data bytes 64 bytes from 172.16.14.12: icmp_seq=0 ttl=255 time=0.571 ms 64 bytes from 172.16.14.12: icmp_seq=1 ttl=255 time=0.361 ms 64 bytes from 172.16.14.12: icmp_seq=2 ttl=255 time=0.371 ms ----marie PING Statistics---- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.361/0.434/0.571/0.118 ms
Non solo ping ci dice se un host è vivo, ci dice quanto questo prende e alla fine dà un pò di utili dettagli. Se un host non può essere risolto, può essere allo stesso modo specificato semplicemente l'indirizzo IP:
#ping -c 1 172.16.20.5PING ash (172.16.20.5): 56 data bytes 64 bytes from 172.16.20.5: icmp_seq=0 ttl=64 time=0.452 ms ----ash PING Statistics---- 1 packets transmitted, 1 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.452/0.452/0.452/0.000 ms
Ora, non diversamente da ogni altro strumento, i tempi sono molto soggettivi, specialmente riguardo alla rete. Per esempio, mentre i tempi negli esempi sono buoni, diamo uno sguardo al ping su localhost:
#ping -c 4 localhostPING localhost (127.0.0.1): 56 data bytes 64 bytes from 127.0.0.1: icmp_seq=0 ttl=255 time=0.091 ms 64 bytes from 127.0.0.1: icmp_seq=1 ttl=255 time=0.129 ms 64 bytes from 127.0.0.1: icmp_seq=2 ttl=255 time=0.120 ms 64 bytes from 127.0.0.1: icmp_seq=3 ttl=255 time=0.122 ms ----localhost PING Statistics---- 4 packets transmitted, 4 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.091/0.115/0.129/0.017 ms
Molto più piccoli perchè la richiesta non lascia mai la macchina. I ping possono essere usati per riunire informazioni su come una rete sia prestante. É anche buono per isolare i problemi, per l'inciso, se ci sono nella rete tre sistemi NetBSD di dimensione relativamente simile e uno di loro semplicemente ha degli orribili tempi di ping, le chances sono qualcosa di sbagliato su quella particalre macchina.
Il comando traceroute(8) è grandioso per assicurarsi se un percorso sia disponibile o rilevare problemi in un particolare percorso. Come esempio, questa è una traccia fra il server ftp di esempio ed ftp.NetBSD.org:
#traceroute ftp.NetBSD.orgtraceroute to ftp.NetBSD.org (204.152.184.75), 30 hops max, 40 byte packets 1 208.44.95.1 (208.44.95.1) 1.646 ms 1.492 ms 1.456 ms 2 63.144.65.170 (63.144.65.170) 7.318 ms 3.249 ms 3.854 ms 3 chcg01-edge18.il.inet.qwest.net (65.113.85.229) 35.982 ms 28.667 ms 21.971 ms 4 chcg01-core01.il.inet.qwest.net (205.171.20.1) 22.607 ms 26.242 ms 19.631 ms 5 snva01-core01.ca.inet.qwest.net (205.171.8.50) 78.586 ms 70.585 ms 84.779 ms 6 snva01-core03.ca.inet.qwest.net (205.171.14.122) 69.222 ms 85.739 ms 75.979 ms 7 paix01-brdr02.ca.inet.qwest.net (205.171.205.30) 83.882 ms 67.739 ms 69.937 ms 8 198.32.175.3 (198.32.175.3) 72.782 ms 67.687 ms 73.320 ms 9 so-1-0-0.orpa8.pf.isc.org (192.5.4.231) 78.007 ms 81.860 ms 77.069 ms 10 tun0.orrc5.pf.isc.org (192.5.4.165) 70.808 ms 75.151 ms 81.485 ms 11 ftp.NetBSD.org (204.152.184.75) 69.700 ms 69.528 ms 77.788 ms
Tutto sommato, niente male. La traccia è andata dall'host nel router locale, allora fuori sulla rete del provider e infine sulla Internet cercando la destinazione finale. Come interpretare i traceroute, di nuovo, sono soggettivi, ma stranamente porzioni di i tempi alti su un percorso possono indicare un ingorgo nelle apparecchiature di un pezzo di rete. Non diversamente da ping, se l'host stesso è sospetto, si esegue traceroute sulla stessa destinaziano da un altro host. Ora, per lo scenario del caso peggiore:
#traceroute www.microsoft.comtraceroute: Warning: www.microsoft.com has multiple addresses; using 207.46.230.220 traceroute to www.microsoft.akadns.net (207.46.230.220), 30 hops max, 40 byte packets 1 208.44.95.1 (208.44.95.1) 2.517 ms 4.922 ms 5.987 ms 2 63.144.65.170 (63.144.65.170) 10.981 ms 3.374 ms 3.249 ms 3 chcg01-edge18.il.inet.qwest.net (65.113.85.229) 37.810 ms 37.505 ms 20.795 ms 4 chcg01-core03.il.inet.qwest.net (205.171.20.21) 36.987 ms 32.320 ms 22.430 ms 5 chcg01-brdr03.il.inet.qwest.net (205.171.20.142) 33.155 ms 32.859 ms 33.462 ms 6 205.171.1.162 (205.171.1.162) 39.265 ms 20.482 ms 26.084 ms 7 sl-bb24-chi-13-0.sprintlink.net (144.232.26.85) 26.681 ms 24.000 ms 28.975 ms 8 sl-bb21-sea-10-0.sprintlink.net (144.232.20.30) 65.329 ms 69.694 ms 76.704 ms 9 sl-bb21-tac-9-1.sprintlink.net (144.232.9.221) 65.659 ms 66.797 ms 74.408 ms 10 144.232.187.194 (144.232.187.194) 104.657 ms 89.958 ms 91.754 ms 11 207.46.154.1 (207.46.154.1) 89.197 ms 84.527 ms 81.629 ms 12 207.46.155.10 (207.46.155.10) 78.090 ms 91.550 ms 89.480 ms 13 * * * .......
In questo caso, anche il server della Microsoft non può essere trovato a causa di indirizzi multipli o da qulche parte lungo la linea un sistema o server non può rispondere alla richiesta di informazioni. A quel punto, uno potrebbe pensare di provare un ping, nel caso della Microsoft, un ping non risponde, questo perchè da qualche parte nella loro rete gli ICMP sono molto probabilmente disabilitati.
Un altro problema che può danneggiare un sistema NetBSD sono legato alla tabella dei percorsi (la cosiddetta routing table, NdT). Questi problemi non sono causati sempre sistema. I comandi route(8) e netstat(1) possono mostrare informazioni sui percorsi (anche noti come route, NdT) e le connessioni di rete (rispettivamente).
Il comando route può essere usato per guardare e modificare la tabella dei percorsi mentre netstat può mostrare informazioni sulle connessioni di rete e i percorsi. Prima, questo è un pò di output mostrato da route:
#route showRouting tables Internet: Destination Gateway Flags default 208.44.95.1 UG loopback 127.0.0.1 UG localhost 127.0.0.1 UH 172.15.13.0 172.16.14.37 UG 172.16.0.0 link#2 U 172.16.14.8 0:80:d3:cc:2c:0 UH 172.16.14.10 link#2 UH marie 0:10:83:f9:6f:2c UH 172.16.14.37 0:5:32:8f:d2:35 UH 172.16.16.15 link#2 UH loghost 8:0:20:a7:f0:75 UH artemus 8:0:20:a8:d:7e UH ash 0:b0:d0:de:49:df UH 208.44.95.0 link#1 U 208.44.95.1 0:4:27:3:94:20 UH 208.44.95.2 0:5:32:8f:d2:34 UH 208.44.95.25 0:c0:4f:10:79:92 UH Internet6: Destination Gateway Flags default localhost UG default localhost UG localhost localhost UH ::127.0.0.0 localhost UG ::224.0.0.0 localhost UG ::255.0.0.0 localhost UG ::ffff:0.0.0.0 localhost UG 2002:: localhost UG 2002:7f00:: localhost UG 2002:e000:: localhost UG 2002:ff00:: localhost UG fe80:: localhost UG fe80::%ex0 link#1 U fe80::%ex1 link#2 U fe80::%lo0 fe80::1%lo0 U fec0:: localhost UG ff01:: localhost U ff02::%ex0 link#1 U ff02::%ex1 link#2 U ff02::%lo0 fe80::1%lo0 U
La sezione flag mostra lo stato e se questo è o meno un gateway. In questo caso abbiamo U, H e G (U è attivo, H è host e G è gateway, vedere la pagina di manuale per flag aggiuntive).
Ora per qualche output di netstat usiamo le opzioni -r (routing) e -n (mostra i numeri di rete):
Routing tables Internet: Destination Gateway Flags Refs Use Mtu Interface default 208.44.95.1 UGS 0 330309 1500 ex0 127 127.0.0.1 UGRS 0 0 33228 lo0 127.0.0.1 127.0.0.1 UH 1 1624 33228 lo0 172.15.13/24 172.16.14.37 UGS 0 0 1500 ex1 172.16 link#2 UC 13 0 1500 ex1 ... Internet6: Destination Gateway Flags Refs Use Mtu Interface ::/104 ::1 UGRS 0 0 33228 lo0 => ::/96 ::1 UGRS 0 0
L'output di sopra è un pò più dettagliato. Dunque, questo come può aiutare? Bene, un buon esempio è quando i percorsi fra le reti vengono cambiati mentre gli utenti sono connessi. Ho visto succedere questo diverse volte quando qualcuno riavvia i router per tutto il giorno dopo ogni cambiamento. Diversi utenti chiamavano dicendo di venire buttati fuori perdevano parecchio tempo prima di riaccedere. Come risultato, i client in connessione sul sistema furono reinstradati su un altro router (che prende percorsi molto lunghi) per riconnettersi. Ho osservato la flag M o Modificato dinamicamente (per reindirizzo) nelle loro connessioni. Ho cancellato i percorsi, li ho fatti riconnettere e sommariamente ho proseguito con l'offendere i tecnici.
Ultimo, è decisamente non per importanza è tcpdump(8), lo sniffer di rete che può ottenere un sacco di informazioni. In questa discussione, ci sarà qualche output di prova e la spiegazione di alcune delle più utili opzioni di tcpdump.
Il seguente è un piccolo ritaglio di tcpdump in azione subito dopo il suo avvio:
#tcpdumptcpdump: listening on ex0 14:07:29.920651 mail.ssh > 208.44.95.231.3551: P 2951836801:2951836845(44) ack 2 476972923 win 17520 <nop,nop,timestamp 1219259 128519450> [tos 0x10] 14:07:29.950594 12.125.61.34 > 208.44.95.16: ESP(spi=2548773187,seq=0x3e8c) (DF) 14:07:29.983117 smtp.somecorp.com.smtp > 208.44.95.30.42828: . ack 420285166 win 16500 (DF) 14:07:29.984406 208.44.95.30.42828 > smtp.somecorp.com.smtp: . 1:1376(1375) ack 0 win 7431 (DF) ...
Dato che il particolare server è un server di posta, quello che mostra ha perfettamente senso, tuttavia, l'utilità è molto dettagliata, prefersco iniziare ad eseguire tcpdump senza opzioni e inviare l'output testuale su un file per successivi esami tipo così:
#tcpdump > tcpdump.outtcpdump: listening on ex0
Dunque, cosa stiamo cercando precisamente in quel trambusto? In breve, ogni cosa che non sembri al posto giusto, per esempio, lunghezze mancanti nei pacchetti (come in un sacco di questi) mostreranno una lunghezza impropria o pacchetti malformati (essenzialmente immondizia). Se, tuttavia, stiamo cercando qualcosa di specifico, tcpdump può essere in grado di aiutare a seconda del problema.
Questi sono solo esempi di poche cose che è possibile fare con tcpdump.
Cercare indirizzi IP duplicati:
tcpdump -e host ip-addressPer esempio:
tcpdump -e host 192.168.0.2Problemi di percorsi:
tcpdump icmpC'è un'abbondanza di strumenti di terze parti disponibili, tuttavia, NetBSD esce con un buon insieme di tool per tracciare problemi a di prestazioni a livello rete.
Il sistema NetBSD esce uquipaggiato con una vasta gamma di monitor per il monitoraggio attivo delle prestazioni, ma cosa in merito al monitoraggio a lungo termine? Bene, naturalmente l'output di una varietà di comandi può esesere inviato a file è rianalizzato in seguito con significativi script per la shell o programmi. NetBSD, di default, offre un pò di straordinari e potenti strumenti di monitoraggio a basso livello per programmatori, amministratori o hobbisti realmente astuti.
Mentre l'accounting dà un utilizzo di sistema quasi a livello userland, il kernel profiling con gprof fornisce un uso esplicito con chiamate di sistema.
Usare gli strumenti di accounting può aiutare a trovare quali possibili problemi di prestazioni possono essere messi in attesa, per incrementare l'utilizzo di compilatori o i servizi di rete per esempio.
Cominciando con l'accounting è ragionevolmente semplice, da root, usare il comando accton(8). La sintasi per avviare l'accounting è: accton nomefile.
Dove le informazioni di accounting sono accodate su nomefile, ora,
abbastanza sconosciuto, il comando lastcomm che legge da un file
di output dell'accounting, di default, guarda in
/var/account/acct così tendo a usare
semplicemente la posizione di default, tuttavia, lastcomm può
essere istruito a guardare altrove.
Per fermare l'accounting semplicemente digitare accton senza argomenti.
Per leggere le informiazioni di accounting, ci sono due strumenti che possono essere usati:
Il comando lastcomm mostra gli ultimi comandi eseguiti in ordine, come ognuno di loro. Può, tuttavia, selezionare per utente, questo è un esempio di output:
$lastcomm jrflast - jrf ttyp3 0.00 secs Tue Sep 3 14:39 (0:00:00.02) man - jrf ttyp3 0.00 secs Tue Sep 3 14:38 (0:01:49.03) sh - jrf ttyp3 0.00 secs Tue Sep 3 14:38 (0:01:49.03) less - jrf ttyp3 0.00 secs Tue Sep 3 14:38 (0:01:49.03) lastcomm - jrf ttyp3 0.02 secs Tue Sep 3 14:38 (0:00:00.02) stty - jrf ttyp3 0.00 secs Tue Sep 3 14:38 (0:00:00.02) tset - jrf ttyp3 0.00 secs Tue Sep 3 14:38 (0:00:01.05) hostname - jrf ttyp3 0.00 secs Tue Sep 3 14:38 (0:00:00.02) ls - jrf ttyp0 0.00 secs Tue Sep 3 14:36 (0:00:00.00) ...
Molto carino, il comando lastcomm ottiene le sue informazioni dalla posizione di default di /var/account/acct, tuttavia, usando l'opzione -f, può essere specificato un altro file.
Come può sembrare ovvio, l'output di lastcomm potrebbe diventare un pò pesante su grandi sistemi multi utente. Quì è dove sa entra in gioco.
Il comando sa (significa "mostra statistiche dell'accounting di sistema") può essere usato per mantenere informazioni. Può anche essere usato interattivamente per creare rapporti. Il seguente è l'output di difault di sa:
$sa77 18.62re 0.02cp 8avio 0k 3 4.27re 0.01cp 45avio 0k ispell 2 0.68re 0.00cp 33avio 0k mutt 2 1.09re 0.00cp 23avio 0k vi 10 0.61re 0.00cp 7avio 0k ***other 2 0.01re 0.00cp 29avio 0k exim 4 0.00re 0.00cp 8avio 0k lastcomm 2 0.00re 0.00cp 3avio 0k atrun 3 0.03re 0.00cp 1avio 0k cron* 5 0.02re 0.00cp 10avio 0k exim* 10 3.98re 0.00cp 2avio 0k less 11 0.00re 0.00cp 0avio 0k ls 9 3.95re 0.00cp 12avio 0k man 2 0.00re 0.00cp 4avio 0k sa 12 3.97re 0.00cp 1avio 0k sh ...
Da sinista a destra, il tempo totale chiamato, tempo reale in miniuti, somma del tempo dell'utente e di sistema, in minuti, numero medio delle operazioni di I/O per esecuzione, dimensione, nome del comando.
Il comando sa può anche essere usato per creare sommari è rapporti basati su qualche opzione, per esempio, questo è l'output quando si specifica una memoria di utilizzo media ordinata per tempo di CPU:
$sa -k86 30.81re 0.02cp 8avio 0k 10 0.61re 0.00cp 7avio 0k ***other 2 0.00re 0.00cp 3avio 0k atrun 3 0.03re 0.00cp 1avio 0k cron* 2 0.01re 0.00cp 29avio 0k exim 5 0.02re 0.00cp 10avio 0k exim* 3 4.27re 0.01cp 45avio 0k ispell 4 0.00re 0.00cp 8avio 0k lastcomm 12 8.04re 0.00cp 2avio 0k less 13 0.00re 0.00cp 0avio 0k ls 11 8.01re 0.00cp 12avio 0k man 2 0.68re 0.00cp 33avio 0k mutt 3 0.00re 0.00cp 4avio 0k sa 14 8.03re 0.00cp 1avio 0k sh 2 1.09re 0.00cp 23avio 0k vi
Il comando sa è molto utile su grandi sistemi.
I rapporti di accounting, come menzionato prima, offrono un modo per aiutare a predire le tendenze, per esempio, un sistema in cui cc e make vengono utilizzati molto può indicare che in pochi mesi qualche cambiamento è necessario per lasciare il sistema in esecuzione a un livello ottimo. Un altro buon esempio è l'utilizzo del server web. Se viene gradualmente incrementato, di nuovo, può essere necessario intraprendere un qualche tipo di azione prima che questo diventi un problema. Fortunatamente, con gli strumenti di accounting, dette azioni possono essere ragionevolmente predette e pianificate per tempi futuri.
Il profiling del kernel è normalmente impiegato quando l'obiettivo è di confrontare la differenza dei nuovi cambiamente nel kernel con uno precedente o per tracciare un qualche tipo di problema di prestazioni a basso livello. Riguardo al comportamento del codice profilato sono registrati indipentemente due insiemi di dati: frequenza delle chiamate di sistema e tempo speso per ogni funzione.
Primo, dare un'occhiata a entrambe Section 18.9, “Tuning del Kernel”
e Chapter 31, Compiling the kernel. L'unica differenza nella procedura
per configurare un kernel col profiling abilitato è quando si
esegue config aggiungendo l'opzione -p. L'area di compilazione è
../compile/<KERNEL_NAME>.PROF, per esempio,
un kernel GENERIC sarebbe ../compile/GENERIC.PROF.
Quanto segue è un rapido sommario di come compilare un kernel
col profiling abilitato su un port i386, i presupposti sono che i
sorgenti appropriati siano disponibile sotto /usr/src
e la configurazione GENERIC venga usata, naturalmente, non è
sempre questa la situazione:
cd /usr/src/sys/arch/i386/conf
config -p GENERIC
cd ../compile/GENERIC.PROF
make depend && make
cp /netbsd /netbsd.old
cp netbsd /
reboot
Una volte che il nuovo kernel sia collocato e il sistema riavviato, è tempo di attivare il monitoraggio è cominciare ad osservare i risultati.
Cominciare con kgmon:
$kgmon -bkgmon: kernel profiling is running.
Successivamente, inviare i dati nel file
gmon.out:
$kgmon -p
Ora, è tempo di rendere l'output leggibile:
$gprof /netbsd > gprof.out
Dal momento che gmon stà cercando gmon.out,
dovrebbe essere trovato nella directory di lavoro corrente.
Eseguendo kgmon da solo, si potrebbe non ottene le informazioni necessarie, tuttavia, se si stanno confrontando le differenze tra due kernel differenti, allora dovrebbe essere utilizzato un ben noto punto di partenza. Si noti che è generalmente una buona idea stressare il sottosistema se si conosce in entrambe il punto di partenza e con il nuovo (o differente) kernel.
Ora che kgmon può girare, collezionare e analizzare informazioni, è tempo di guardare effettivamente qualche informazione. In questa particolare caso, un kernel GENERIC è in esecuzione con il profiling abilitato da circa un ora con solo i processi di sistema e nessun pesante carico, nella sezione con l'inserimento difettoso, l'esempio sarà grande abbastanza che anche sotto un carico medio la rilevazione del problema dovrebbe essere facile.
Il piano di profile è una lista di funzioni, il numero di volte che queste vengono chiamate e quanto tempo prendono (in secondi). Il seguente è un esempio di output da un sistema tranquillo:
Flat profile: Each sample counts as 0.01 seconds. % cumulative self self total time seconds seconds calls ns/call ns/call name 99.77 163.87 163.87 idle 0.03 163.92 0.05 219 228310.50 228354.34 _wdc_ata_bio_start 0.02 163.96 0.04 219 182648.40 391184.96 wdc_ata_bio_intr 0.01 163.98 0.02 3412 5861.66 6463.02 pmap_enter 0.01 164.00 0.02 548 36496.35 36496.35 pmap_zero_page 0.01 164.02 0.02 Xspllower 0.01 164.03 0.01 481968 20.75 20.75 gettick 0.01 164.04 0.01 6695 1493.65 1493.65 VOP_LOCK 0.01 164.05 0.01 3251 3075.98 21013.45 syscall_plain ...
Come previsto, l'idle era il più alto in percentuale, tuttavia, c'erano ancora un pò di cose attive, per esempio, un pò più avanti c'è la funzione vn_lock:
... 0.00 164.14 0.00 6711 0.00 0.00 VOP_UNLOCK 0.00 164.14 0.00 6677 0.00 1493.65 vn_lock 0.00 164.14 0.00 6441 0.00 0.00 genfs_unlock
Questo è da predire, dal momento che il blocco deve ancora aver luogo, indipendentemente.
Il grafico di chiamata è una versione aumentata del piano di profilo mostrando sottosequenze di chiamate per le funzioni elencate. Primo, ecco un esempio di output:
Call graph (explanation follows)
granularity: each sample hit covers 4 byte(s) for 0.01% of 164.14 seconds
index % time self children called name
<spontaneous>
[1] 99.8 163.87 0.00 idle [1]
-----------------------------------------------
<spontaneous>
[2] 0.1 0.01 0.08 syscall1 [2]
0.01 0.06 3251/3251 syscall_plain [7]
0.00 0.01 414/1660 trap [9]
-----------------------------------------------
0.00 0.09 219/219 Xintr14 [6]
[3] 0.1 0.00 0.09 219 pciide_compat_intr [3]
0.00 0.09 219/219 wdcintr [5]
-----------------------------------------------
...
Ora questo può confondere un pò. Il numero di indice è tracciato dall'ultimo alla fine della linea, per esempio:
...
0.00 0.01 85/85 dofilewrite [68]
[72] 0.0 0.00 0.01 85 soo_write [72]
0.00 0.01 85/89 sosend [71]
...
Quì vediamo che dofilewrite è stata chiamata prima, ora guardiamo al numero d'indice per 64 e vediamo cosa succede lì:
...
0.00 0.01 101/103 ffs_full_fsync <cycle 6> [58]
[64] 0.0 0.00 0.01 103 bawrite [64]
0.00 0.01 103/105 VOP_BWRITE [60]
...
E così via, in questo modo, può essere stabilita una "traccia visuale".
Alla fine del grafico della chiamata subito dopo la sezione dei termini c'è un indice per nome di funzione che può aiutare a tracciare gli indici allo stesso modo.
In questo esempio, ho modificato un'area del kernel di cui sò che creerà un problema che ostruirà in maniera evidente.
Questa è la porzione superiore del piano di profilo dopo aver fatto girare il sistema per circa un'ora con un pò di interazione degli utenti:
Flat profile: Each sample counts as 0.01 seconds. % cumulative self self total time seconds seconds calls us/call us/call name 93.97 139.13 139.13 idle 5.87 147.82 8.69 23 377826.09 377842.52 check_exec 0.01 147.84 0.02 243 82.30 82.30 pmap_copy_page 0.01 147.86 0.02 131 152.67 152.67 _wdc_ata_bio_start 0.01 147.88 0.02 131 152.67 271.85 wdc_ata_bio_intr 0.01 147.89 0.01 4428 2.26 2.66 uvn_findpage 0.01 147.90 0.01 4145 2.41 2.41 uvm_pageactivate 0.01 147.91 0.01 2473 4.04 3532.40 syscall_plain 0.01 147.92 0.01 1717 5.82 5.82 i486_copyout 0.01 147.93 0.01 1430 6.99 56.52 uvm_fault 0.01 147.94 0.01 1309 7.64 7.64 pool_get 0.01 147.95 0.01 673 14.86 38.43 genfs_getpages 0.01 147.96 0.01 498 20.08 20.08 pmap_zero_page 0.01 147.97 0.01 219 45.66 46.28 uvm_unmap_remove 0.01 147.98 0.01 111 90.09 90.09 selscan ...
Come è ovvio, c'è una grande differenza in prestazioni. Togliendo il blocco il tempo di idle è notevolmente minore. La differenza principale quì è che una particolare funzione ha un grosso tempo attraverso i bordi con pochissime chiamate. Quella funzione è check_exec. Mentre in principio, questo potrebbe non sembrare strano se ci sono stati eseguiti un sacco di comandi, quando confrontato al piano di profilo della prima misura, proporzionalmente non sembra corretto:
... 0.00 164.14 0.00 37 0.00 62747.49 check_exec ...
La chiamata nella prima stima è fatta 37 volte e ha delle prestazioni migliori. Ovviamente qualcosa in o attorno a questa funzione è sbagliata. Per eliminare altre funzioni, uno sguardo al grafico della chiamata può aiutare, questa è la prima istanza di check_exec
...
-----------------------------------------------
0.00 8.69 23/23 syscall_plain [3]
[4] 5.9 0.00 8.69 23 sys_execve [4]
8.69 0.00 23/23 check_exec [5]
0.00 0.00 20/20 elf32_copyargs [67]
...
Notare come il tempo di 8.69 sembra influenzare le due funzioni precedenti. É possibile the ci sia qualcosa di errato con loro, tuttavia, la prossima istanza di check_exec sembra dimostrare il contrario:
...
-----------------------------------------------
8.69 0.00 23/23 sys_execve [4]
[5] 5.9 8.69 0.00 23 check_exec [5]
...
Adesso possiamo vedere che il problema, molto probabilmente,
risiede in check_exec. Naturalmente,
i problemi non sono sempre di questa semplicità e
infatti, ecco il codice simpleton inserito subito dopo
check_exec (la funzione è in
sys/kern/kern_exec.c):
...
/* A Cheap fault insertion */
for (x = 0; x < 100000000; x++) {
y = x;
}
..
Non esattamente clamoroso, ma abbastanza per registrare grossi cambiamenti col profiling.
Il profiling del kernel può essere alleggerito per ognuno e fornisce un metodo molto più ridefinito di cacciare i problemi di perstazioni che non sono facili da trovare usando i metodi convenzionali, inoltre non è così difficile come molte persone credono, se si può compilare un kernel, si può far funzionare il profiling.
Ora che gli strumenti di monitoraggio e analisi sono stati introdotti, è tempo di guardare su un pò di metodi veri e propri. In questa sezione, sono introdotti gli strumenti e i metodi che possono influenzare le prestazioni del sistema che sono applicati senza ricompilare il kernel, la prossima sezione esamine il tuning del kernel ricompilando.
Il programma di utilità sysctl può essere usato per vedere e in alcuni casi alterare i parametri di sistema. Ci sono così tanti parametri che possono essere visti e cambiati da non poter essere mostrati tutti quì, tuttavia, per il primo esempio c'è un semplice uso di sysctl per guardare alla variabile d'ambiente relativa al PATH di sistema:
$sysctl user.cs_pathuser.cs_path = /usr/bin:/bin:/usr/sbin:/sbin:/usr/pkg/bin:/usr/pkg/sbin:/usr/local/bin:/usr/local/sbin
Ragionevolmente semplice. Ora qualcosa che sia effettivamente relativo alle prestazioni. Come esempio, basti guardare a un sistema con molti utenti che stà avendo problemi con i file aperti, esaminando e forse aumentando il parametro kern.maxfiles il problema può essere risolto, ma prima, un'occhiata:
$sysctl kern.maxfileskern.maxfiles = 1772
Ora, cambiamolo, da root specificando l'opzione -w:
#sysctl -w kern.maxfiles=1972kern.maxfiles: 1772 -> 1972
Nota, quando il sistema si riavvia, verrà rimesso il
vecchio valore, ci sono due rimedi per questo, primo, modificare
il parametro nel kernel e ricompilare, secondo (e più
semplice) aggiungere questa linea su
/etc/sysctl.conf:
kern.maxfiles=1972
Un sistema operativo può spesso beneficiare da pochi cambi nella configurazione (seguendo le stesse linee, è anche possibile danneggiarlo). Due casi particolari dove le prestazioni del sistema possono essere cambiato sono utilizzando dei file system basati sulla memoria e/o i soft update.
Quando usare e non usare i file system basati sulla memoria
può essere difficile su grossi sistemi multi utente.
In alcuni casi, tuttavia, ha decisamente senso, per esempio,
su una macchina di sviluppo usata solo da uno sviluppatore
alla volta, per la compilazione la directory obj o qualcuna
delle directory tmp, potrebbe essere un buon posto. Un caso
del genere, ha senso su macchine che hanno una giusta
quantità di RAM. L'altra faccia della moneta, se un
sistema ha solo 16MB di RAM e /var/tmp
è basato su memfs, si potrebbero verificare parecchi
problemi di applicazioni.
Il kernel GENERIC ha memfs abilitato di default. Per usarlo
su una particolare directory prima si determina dov'è
lo spazio di swap che si desidera utilizzare, nel caso di
esempio, uno sguardo rapido a /etc/fstab
indica che /dev/wd0b è la
partizione di swap:
mail% cat /etc/fstab /dev/wd0a / ffs rw 1 1 /dev/wd0b none swap sw 0 0 /kern /kern kernfs rw
Questo sistema è un server di posta così
voglio usare solo /tmp con memfs,
inoltre su questo particolare file system ho collegato
(tramite un link simbolico, NdT) /tmp
a /var/tmp per risparmiare spazio
(entrambe sono sullo stesso disco). Tutto ciò che
devo fare è aggiungere la seguente voce:
/dev/wd0b /var/tmp mfs rw 0 0
Ora, un avvertimento, assicurarsi che dette directory siano vuote e niente le stia utilizzando quando si monta il file system basato di memoria! A questo punto posso fare mount -a o riavviare il sistema.
Le dipendenze morbide (cosiddette soft-dependencies, NdT) è un meccanismo che non scrive i meta-dati su disco immediatamente, ma questi sono scritti in modo ordinato, il quale mantiene il file system consistente.
Le soft-dependencies possono essere abilitate aggiungendo
softdep alle opzioni del file system in
/etc/fstab. Diamo un'occhiata a un
esempio di /etc/fstab:
/dev/wd0a / ffs rw 1 1 /dev/wd0b none swap sw 0 0 /dev/wd0e /var ffs rw 1 2 /dev/wd0f /tmp ffs rw 1 2 /dev/wd0g /usr ffs rw 1 2
Supponiamo di voler abilitare le soft-dependencies per tutti i file system, ecceto per la partizione /. Dovrebbo cambiarlo in (i cambiamenti sono enfatizzati):
/dev/wd0a / ffs rw 1 1 /dev/wd0b none swap sw 0 0 /dev/wd0e /var ffs rw,softdep 1 2 /dev/wd0f /tmp ffs rw,softdep 1 2 /dev/wd0g /usr ffs rw,softdep 1 2
Maggiori informazioni sulle capability delle softdep possono essere trovati nella pagina dell'autore.
Mentre molti parametri di sistema possono essere cambiati con sysctl, molti miglioramenti possono essere allo stesso modo realizzati usando software di sistema elaborati, layout di sistema e di gestione dei servizi (muoverli dentro e fuori da inetd per esempio). Il tuninge del kernel tuttavia fornirà migliori prestazioni, anche se sembrano essere marginali.
Primo, procurarsi i sorgenti del kernel per il rilascio come descritto in Chapter 29, Obtaining the sources, è raccomandato leggere Chapter 31, Compiling the kernel per ulteriori informazioni su come compilare il kernel. Nota, questo documento può essere usato per il tuning di -current, tuttavia, una lettura della documentazione Tracking -current dovrebbe essere fatta prima, molte di quelle informazioni sono ripetute quì.
La configurazione del kernel su NetBSD può essere scoraggiante.
Questo è dovuto alle molteplici linee di dipendenze all'interno
del file di configurazione stesso, tuttavia, c'è un beneficio
in questo metodo ed è, tutto ciò di cui necessita è
un editor ASCII e qualche output di dmesg per avere un nuovo kernel
configurato. Il file de configurazione del kernel è sotto
src/sys/arch/ARCH/conf dove ARCH è
l'architettura (per esempio, su SPARC sarebbe sotto
src/sys/arch/sparc/conf).
Dopo aver localizzato il file di configurazione del kernel, copiarlo e rimuovere (commentare) tutte le voci non necessarie. Questo è il momento in cui dmesg(8) diventa un amico. Un chiaro output di dmesg(8) mostrera tutte le periferiche rilevate dal kernel in fase di avvio. Usando l'output di dmesg(8), possono essere determinate le opzioni della periferica realmente necessarie. Per qualche automazione, controllare il pacchetto "adjustkernel".
In questo esempio, il kernel di un server ftp stà per
essere riconfigurate per girare con i driver e le opzioni strettamente
indispensabili e qualsiasi altra voce possa farlo girare più
velocemente (di nuovo, non necessariamente più piccolo, anche
se lo sarà). La prima cosa da fare e dare un'occhiata a qualche
voce della configurazione principale. Così, su
/usr/src/sys/arch/i386/conf il file GENERIC è
stato copiato su FTP, dunque il file FTP è stato modificato.
All'inizio del file ci sono unas erie di opzioni che cominciano con maxusers, le quali saranno lasciate da sole, tuttavia, su grossi sistemi multi utente potrebbe essere d'aiuto manovrarle un pò. Il prossimo è il supporto della CPU, dall'output di dmesg si può vedere questo:
cpu0: Intel Pentium II/Celeron (Deschutes) (686-class), 400.93 MHz
A indicare the solo le opzioni I686_CPU necessitano di essere usate. Nella prossima sezione, tutte le opzioni saranno lasciate sole eccetto PCI_DELAY che è raccomandata a meno che non sia una vecchia macchina. In questo caso è abilitata vista che 686 è “relativamente nuova”.
Le opzioni successive alla sezione compat non hanno realmente bisogno di avere cambiato niente su questo particolare sistema. Nella sezione compat, tuttavia, ci sono diverse opzioni che non necessitano di essere abilitate, di nuovo questo è perchè questa macchina è prettamente un server FTP, tutte le opzioni compat sono disabilitate.
La prossima sezione è File sistems, e ancora, per questo server molto poco necessita di essere attivo, quanto segue verrà attivato:
# File systems file-system FFS # UFS file-system LFS # log-structured file system file-system MFS # memory file system file-system CD9660 # ISO 9660 + Rock Ridge file system file-system FDESC # /dev/fd file-system KERNFS # /kern file-system NULLFS # loopback file system file-system PROCFS # /proc file-system UMAPFS # NULLFS + uid and gid remapping ... options SOFTDEP # FFS soft updates support. ...
Successivamente viene la sezione con le opzioni di rete. Le uniche opzioni attive sono:
options INET # IP + ICMP + TCP + UDP options INET6 # IPV6 options IPFILTER_LOG # ipmon(8) log support
IPFILTER_LOG è buono averla visto che sul server girerà ipf.
La prossima sezione sono i messaggi dettagliati (verbose, NdT) per i vari sottosistemi, dal momento che questa macchina è già in esecuzione e non ha grossi problemi, sono tutte commentate.
Le voci configurabile nel file di configurazione sono relativamente poche da coprire, tuttavia, i driver di periferica sono una storia differente. Nei seguenti esempi, sono esaminati due driver e le loro “aree” associate nel file tolte. Prima, un piccolo esempio: le seguenti righe sono, il cdrom, in dmesg:
... cd0 at atapibus0 drive 0: <CD-540E, , 1.0A> type 5 cdrom removable cd0: 32-bit data port cd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 2 pciide0: secondary channel interrupting at irq 15 cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2 (using DMA data transfer ...
Ora, è tempo di tracciare quella sezione nel file di configurazione. Notare che "cd"-drive è sull'atapibus è richiede il supporto pciide. La sezione di interesse in questo caso quella "IDE and related devices" nella configurazione del kernel. Vale la pena di notare a questo punto, su e intorno alla sezione IDE ci sono anche ISO, PCMCIA, etc., su questa macchina nell'output di dmesg(8) non ci sono periferiche PCMCIA, così è viene palese che tutti i riferimenti a PCMCIA possono essere rimossi. Ma prima, il drive "cd".
All'inizio della sezione IDE c'è quanto segue:
... wd* at atabus? drive ? flags 0x0000 ... atapibus* at atapi? ...
Well, it is pretty obvious that those lines need to be kept. Next is this:
... # ATAPI devices # flags have the same meaning as for IDE drives. cd* at atapibus? drive ? flags 0x0000 # ATAPI CD-ROM drives sd* at atapibus? drive ? flags 0x0000 # ATAPI disk drives st* at atapibus? drive ? flags 0x0000 # ATAPI tape drives uk* at atapibus? drive ? flags 0x0000 # ATAPI unknown ...
L'unico tipo di periferica che c'era nell'output di dmesg(8) era il cd, il resto può essere commentato.
Il prossimo esempio è leggermente più difficoltoso, interfacce di rete. Questa macchina ne ha due:
... ex0 at pci0 dev 17 function 0: 3Com 3c905B-TX 10/100 Ethernet (rev. 0x64) ex0: interrupting at irq 10 ex0: MAC address 00:50:04:83:ff:b7 UI 0x001018 model 0x0012 rev 0 at ex0 phy 24 not configured ex1 at pci0 dev 19 function 0: 3Com 3c905B-TX 10/100 Ethernet (rev. 0x30) ex1: interrupting at irq 11 ex1: MAC address 00:50:da:63:91:2e exphy0 at ex1 phy 24: 3Com internal media interface exphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ...
A primo impatto può apparire che ci sono di fatto tre periferiche, tuttavia, si guardi attentamente a questa riga:
exphy0 at ex1 phy 24: 3Com internal media interface
Rivela che quella è solo due schede fisiche, non diversamente dal cdrom, semplicemente rimuovere i nomi che non sono in dmesg farà il lavoro. All'inizio della sezione sulle interfacce di rete c'è:
... # Network Interfaces # PCI network interfaces an* at pci? dev ? function ? # Aironet PC4500/PC4800 (802.11) bge* at pci? dev ? function ? # Broadcom 570x gigabit Ethernet en* at pci? dev ? function ? # ENI/Adaptec ATM ep* at pci? dev ? function ? # 3Com 3c59x epic* at pci? dev ? function ? # SMC EPIC/100 Ethernet esh* at pci? dev ? function ? # Essential HIPPI card ex* at pci? dev ? function ? # 3Com 90x[BC] ...
C'è una periferica ex. Così tutto il resto sotto la sezione PCI può essere rimosso. In aggiunta, ogni singola linea al di sotto di questa:
exphy* at mii? phy ? # 3Com internal PHYs
può essere commentata così come le rimanenti.
Quando faccio tuning su un kernel, mi piace farlo da remoto in usa sessione X window, in una finestra l'output di dmesg, nell'altra il file di configurazione. Questo talvolta prende pochi passaggi per ricompilare un kernel molto ripulito visto che è facile cancellare accidentalmente le dipendenze.
Ora è tempo di compilare il kernel e metterlo al suo posto. Nella directory di configurazione nel server ftp, i seguenti comandi preparano la compilazione:
$config FTP
Quando finisce un messaggio ricorda di fare make depend, dopo:
$cd ../compile/FTP$make depend && make
Quando questo è fatto, si fa il backup del vecchio kernel e si sposta il nuovo al suo posto:
#cp /netbsd /netbsd.orig#cp netbsd /
Adesso riavviare. Se il kernel non può avviarsi, interrompere
il processo di avvio è una volta al prompt digitare
boot netbsd.orig per avviare il kernel
precedente.
Quando si compila il kernel per sistemi integrati, è spesso necessario modificare il binario del Kernel per ridurre lo spazio o la memoria occupata.
Sappiamo già come rimuovere il supporto del Kernel per
driver e opzioni non necessarie, risparmiando così memoria
e spazio, ma si può salvare qualche KiloByte di spazio
rimuovendo i simboli di debug e le due sezioni ELF se non servono:
.comment e .ident. Queste
sono usate per contenere stringhe RCS visibili con ident(1)
e una stringa di versione di gcc(1). I seguenti esempi
suppongono si abbia TOOLDIR sotto
/usr/src/tooldir.NetBSD-2.0-i386 e
l'architettura in questione siai386.
$/usr/src/tooldir.NetBSD-2.0-i386/bin/i386--netbsdelf-objdump -h /netbsd/netbsd: file format elf32-i386 Sections: Idx Name Size VMA LMA File off Algn 0 .text 0057a374 c0100000 c0100000 00001000 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .rodata 00131433 c067a380 c067a380 0057b380 2**5 CONTENTS, ALLOC, LOAD, READONLY, DATA 2 .rodata.str1.1 00035ea0 c07ab7b3 c07ab7b3 006ac7b3 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA 3 .rodata.str1.32 00059d13 c07e1660 c07e1660 006e2660 2**5 CONTENTS, ALLOC, LOAD, READONLY, DATA 4 link_set_malloc_types 00000198 c083b374 c083b374 0073c374 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 5 link_set_domains 00000024 c083b50c c083b50c 0073c50c 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 6 link_set_pools 00000158 c083b530 c083b530 0073c530 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 7 link_set_sysctl_funcs 000000f0 c083b688 c083b688 0073c688 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 8 link_set_vfsops 00000044 c083b778 c083b778 0073c778 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 9 link_set_dkwedge_methods 00000004 c083b7bc c083b7bc 0073c7bc 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 10 link_set_bufq_strats 0000000c c083b7c0 c083b7c0 0073c7c0 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 11 link_set_evcnts 00000030 c083b7cc c083b7cc 0073c7cc 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 12 .data 00048ae4 c083c800 c083c800 0073c800 2**5 CONTENTS, ALLOC, LOAD, DATA 13 .bss 00058974 c0885300 c0885300 00785300 2**5 ALLOC 14 .comment 0000cda0 00000000 00000000 00785300 2**0 CONTENTS, READONLY 15 .ident 000119e4 00000000 00000000 007920a0 2**0 CONTENTS, READONLY
Nella terza colonna si può vedere la dimensione delle
sezioni in forma esadecimale. Sommando le dimensioni di
.comment e .ident
sappiamo quanto stiamo andando a salvare con la loro
rimozione: intorno ai 120KB (= 52640 + 72164 = 0xcda0 + 0x119e4).
Per rimuovere le sezioni e i simboli di debug che possono
essere presenti, andiamo ad usare strip(1):
#cp /netbsd /netbsd.orig#/usr/src/tooldir.NetBSD-2.0-i386/bin/i386--netbsdelf-strip -S -R .ident -R .comment /netbsd#ls -l /netbsd /netbsd.orig-rwxr-xr-x 1 root wheel 8590668 Apr 30 15:56 netbsd -rwxr-xr-x 1 root wheel 8757547 Apr 30 15:56 netbsd.orig
Visto che abbiamo rimosso anche i simboli di debug, il conteggio totali di spazio disco salvato è intorno ai 160KB.
Su alcune architetture, il bootloader può avviare un kernel compresso. É possibile salvare MegaByte di spazio disco usando questo metodo, ma il bootloader richiederà più tempo per caricare il kernel.
#cp /netbsd /netbsd.plain#gzip -9 /netbsd
Per vedere quanto spazio è stato salvato:
$ls -l /netbsd.plain /netbsd.gz-rwxr-xr-x 1 root wheel 8757547 Apr 29 18:05 /netbsd.plain -rwxr-xr-x 1 root wheel 3987769 Apr 29 18:05 /netbsd.gz
Nota che si può solo utilizzare la codifica gzip, usando gzip(1), bzip2 non è supportato da NetBSD.