In questo articolo descriveremo l'insieme minimo di azioni necessarie per un'installazione ottimale del DBMS Firebird versione 3.0 su nuove distribuzioni di Linux. Come esempi sono stati scelti CentOS 8 e Ubuntu 19.
Per la "consegna" della distribuzione di Firebird al sistema target, in questa guida, è stata scelta l'opzione di scaricare un archivio tar.gz tramite un link dal sito ufficiale del progetto ().
Per i più impazienti — subito in azione:
Installazione rapida
Modifichiamo il file /etc/sysctl.conf, aggiungendo la riga:
vm.max_map_count = 256000
Salviamo il file e applichiamo la configurazione:
sudo sysctl -p /etc/sysctl.conf
Le istruzioni seguenti variano per CentOS 8 e Ubuntu 19, ma LINK e CARTELLO indicano il link al sito ufficiale del progetto Firebird per il download della distribuzione e la cartella in cui verrà estratta la distribuzione durante il download.
Attualmente (marzo 2020), è disponibile la versione Firebird 3.0.5 ( per la versione a 64 bit).
CentOS 8
sudo yum -y install epel-release
sudo yum -y makecache
sudo yum -y install libicu libtommath tar
ln -s libncurses.so.5
/usr/lib64/libncurses.so.5
ln -s libtommath.so.1
/usr/lib64/libtommath.so.0
curl -L LINK|tar -zxC /tmp
Ubuntu 19
sudo apt-get -y install libncurses5 libtommath1
ln -s libtommath.so.1
/usr/lib/x86_64-linux-gnu/libtommath.so.0
wget -O- LINK|tar -zxC /tmp
In realtà, installazione del DBMS Firebird:
cd /tmp/CARTELLO
sudo ./install.sh
Se vuoi capire meglio a cosa servono queste azioni, continua a leggere.
Parte principale
Una piccola introduzione
Si presume che il sistema operativo sia già installato in versione minima e che sia stato configurato l'accesso ai repository pubblici o alle loro copie locali.
Si presume che il lettore abbia conoscenze di base su Linux e sul DBMS Firebird.
Pianificazione
Sul server DBMS si consiglia di dedicare partizioni separate per i file temporanei (/tmp), i file del database e i backup locali.
I file temporanei includono i file di lock, i file di ordinamento, i file di "materializzazione" delle tabelle temporanee globali (GTT) e delle tabelle di monitoraggio. I file di ordinamento e delle tabelle temporanee globali si trovano in /tmp, i file delle mon$-tabelle e i file di lock – in /tmp/firebird.
I file di ordinamento vengono "eliminati" (unlink) subito dopo la creazione, quindi non possono essere "visti" nell'elenco della cartella — solo nell'elenco dei descrittori (handles) del processo (contrassegnati come deleted):
sudo ls -lhF /proc/`pgrep firebird`/fd
Nell'elenco del pseudo-cartella /proc/…/fd/ vengono visualizzati i symlink, e le informazioni effettive sul file sono date da:
sudo stat -L /proc/`pgrep firebird`/fd/NOME
dove NOME – descrittore del file di interesse.
Invece di invocare "pgrep eseguibile-file» puoi subito inserire l'identificativo del processo di tuo interesse.
I file temporanei possono essere molto grandi, quindi è /tmp consigliabile allocare almeno 20-30 GB. Tieni presente che la dimensione dei file di ordinamento dipende solo dalla quantità di dati, esplicitamente o implicitamente ordinati nella query, e un solo utente può "creare" gigabyte di file temporanei.
Il settore per i file dei database deve contenere i file di tutti i database, più, almeno, una copia del file del database più grande. È importante considerare la crescita dei file dei database a lungo termine, per alcuni anni.
Il settore dei backup locali deve contenere, almeno, un archivio di backup per ogni database, oltre al backup del database più grande. È preferibile che in questo settore ci sia anche spazio per il ripristino del database più grande. È necessario tenere conto della crescita dei backup e degli archivi dei backup a lungo termine.
Preparazione preliminare
Il server DBMS Firebird 3.0 gestisce dinamicamente l'allocazione e il rilascio della memoria di sistema, il che può portare a una frammentazione. Ad esempio, dopo la disconnessione simultanea di un grande numero di utenti dal superserver, possono verificarsi errori nelle nuove connessioni.
La frammentazione della memoria è controllata dal parametro di sistema vm.max_map_count, per impostazione predefinita – 64K. Si consiglia di aumentarne il valore di quattro volte:
sudo sysctl vm.max_map_count=256000
Affinché il nuovo valore venga impostato al riavvio del sistema, aggiungiamo al file /etc/sysctl.conf la seguente riga:
vm.max_map_count = 256000
È consigliabile fare un commento per chiarire il motivo della modifica di questo parametro. È possibile modificare il file e poi applicare le impostazioni salvate in esso:
sudo sysctl -p /etc/sysctl.conf
Installazione dei pacchetti necessari
I file eseguibili del DBMS Firebird 3.0 per Linux dipendono dalle librerie ncurses (libncurses.so.5), ICU (senza vincoli di versione e senza visualizzazione nell'output ldd) e tommath (libtommath.so.0). Per scaricare e decomprimere l'archivio della build saranno necessarie le utility gzip, tar e curl o wget. Le versioni di ICU, gzip, tar e curl/wget non sono significative.
Il lavoro con i pacchetti dipende dal sistema e dal gestore di pacchetti utilizzato nel sistema, quindi li esamineremo uno per uno.
CentOS 8
CentOS 8 utilizza un nuovo gestore di pacchetti – dnf ed è anche "trasparente" richiamato con il comando yum. Poiché per i nostri scopi non c'è differenza tra loro, negli esempi utilizzeremo yum.
Aggiorniamo la cache dei metadati: sudo yum makecache
Il pacchetto libtomath si trova in un repository E(xtra)P(ackages for)E(nterprise)L(inux) separato, quindi controlliamo che sia già collegato:
yum -C repolist
L'opzione "solo dalla cache" (-C o --cache-only) viene utilizzata per escludere controlli e download non necessari, accelerando il funzionamento di yum. Se l'epel-repository non è nella lista, lo installiamo e aggiorniamo la cache dei metadati:
sudo yum install epel-release &&
sudo yum makecache
Confermiamo le richieste, confrontando i valori delle chiavi pgp con quelli già conosciuti da una fonte fidata.
Se ci sono problemi nel scaricare le informazioni di metadati dal repository su risorse https, modifichiamo il file /etc/yum.repos.d/epel.repo, sostituendo https:// in http:// e ripetiamo il comando di aggiornamento della cache.
Controlliamo lo stato dei pacchetti necessari (il comando è composto, nell'esempio l'output è filtrato per pacchetto a 32 bit):
yum -C list
ncurses libicu libtommath
gzip tar curl wget |
grep -v i686
Pacchetti installati
curl.x86_64 7.61.1-11.el8 @anaconda
gzip.x86_64 1.9-9.el8 @anaconda
ncurses.x86_64 6.1-7.20180224.el8 @anaconda
Pacchetti disponibili
libicu.x86_64 60.3-1.el8 BaseOS
libtommath.x86_64 1.1.0-1.el8 epel
tar.x86_64 2:1.30-4.el8 BaseOS
wget.x86_64 1.19.5-8.el8_1.1 AppStream
Vediamo che curl, gzip e ncurses sono posizionati nel pseudo-repository dell'installer (anaconda), e tar – escluso dall'installazione minima del sistema. Le versioni maggiori libncurses e libtommath sono maggiori di quelle richieste: 6 e 1 invece di 5 e 0, rispettivamente. Se lo stesso pacchetto è installato e disponibile, è stata rilasciata un'aggiornamento. Installiamo i pacchetti mancanti:
sudo yum install
libicu libtommath tar
Ubuntu 19
Per gestire i pacchetti sono destinate le utility apt, apt‑get e apt‑cache. Il primo è pensato per un lavoro interattivo, mentre gli ultimi due sono destinati all'uso negli script. I nomi dei pacchetti sono leggermente diversi e includono la versione.
Controlliamo lo stato dei pacchetti necessari (il comando è composto, l'esempio di output è accorciato e filtra i pacchetti a 32 bit):
apt list libncurses? libicu?? libtommath?
gzip tar curl wget |
grep -v i386
curl 7.65.3-1
gzip 1.10-0 [aggiornabile...]
libicu63 63.2-2 [installato]
libncurses5 6.1
libncurses6 6.1 [installato, automatico]
libtommath1 1.1.0
tar 1.30 [installato]
wget 1.20.3 [installato]
Pacchetti per i quali tra parentesi quadre è indicato installato/aggiornabile – installati. Disponibile, ma non installato ncurses5, invece di curl è installato wget. Installiamo i pacchetti mancanti:
sudo apt‑get install
libncurses5 libtommath1
Creazione di symlink
Poiché libtommath.so.1 e libncurses.so.6 sono retrocompatibili con libtommath.so.0 e libncurses.so.5, per Firebird è sufficiente creare symlink sulle versioni esistenti delle librerie.
Troviamo libtommath.so.1 (libncurses.so.? si trovano nella stessa directory):
find /usr -name libtommath.so.1
CentOS:
/usr/lib64/libtommath.so.1
Ubuntu:
/usr/lib/x86_64-linux-gnu/libtommath.so.1
Creiamo symlink.
CentOS:
sudo ln -s libtommath.so.1
/usr/lib64/libtommath.so.0
sudo ln -s libncurses.so.6
/usr/lib64/libncurses.so.5
Ubuntu:
sudo ln -s libtommath.so.1
/usr/lib/x86_64-linux-gnu/libtommath.so.0
Verifichiamo il risultato (il comando è stato eseguito, gli esempi di output sono stati abbreviati):
ls -lhF
$(dirname `find /usr -name libtommath.so.1`) |
grep "lib(ncurses|tommath).so."
CentOS:
libncurses.so.5 -> libncurses.so.6*
libncurses.so.6 -> libncurses.so.6.1*
libncurses.so.6.1*
libtommath.so.0 -> libtommath.so.1*
libtommath.so.1 -> libtommath.so.1.1.0*
libtommath.so.1.1.0*
Ubuntu:
libncurses.so.5 -> libncurses.so.5.9
libncurses.so.5.9
libncurses.so.6 -> libncurses.so.6.1
libncurses.so.6.1
libtommath.so.0 -> libtommath.so.1
libtommath.so.1 -> libtommath.so.1.1.0
libtommath.so.1.1.0
Download del pacchetto del DBMS Firebird.
Nel sito ufficiale del progetto Firebird (firebirdsql.org) vengono pubblicati collegamenti ai pacchetti delle "versioni ufficiali" (releases) e delle "compilazioni quotidiane" (snapshot build).
Le versioni ufficiali per Linux sono disponibili in archivi (tar.gz) e pacchetti deb/rpm, mentre le compilazioni sono disponibili solo come archivi. Considereremo il "installer generico" (generic installer in tar.gz).
È necessario scaricare e decomprimere l'archivio della compilazione, ma possiamo combinare entrambi i processi. La decompressione avviene in /tmp, l'URL indica il collegamento all'archivio da scaricare.
curl:
curl -L URL | tar -zxC /tmp
wget:
wget -O– URL | tar -zxC /tmp
Per impostazione predefinita curl invia i dati scaricati all'output standard, ma non gestisce i reindirizzamenti, quindi aggiungiamo "-L", mentre wget, al contrario: gestisce i reindirizzamenti, ma scrive i dati in un file e utilizziamo "-O-". Per tar indichiamo l'uso gzip-filtra e la directory in cui verrà eseguita la decompressione. Al termine del processo, verrà creato un catalogo del tipo Firebird-3.0.5.33220-0.amd64 con tre file: install.sh, buildroot.tar.gz e manifest.txt.
Installazione di Firebird
Durante la preparazione iniziale abbiamo regolato il valore del parametro di sistema vm.max_map_count, verificato la presenza e installato le librerie ICU, ncurses e tommath. Abbiamo confermato la correttezza delle versioni di ncurses e tommath (libncurses.so.5 e libtommath.so.0) e creato i collegamenti simbolici necessari.
L'installazione vera e propria è molto semplice. Accediamo alla cartella dove è stato estratto l'archivio del pacchetto Firebird, verifichiamo e, se necessario, impostiamo il flag "eseguibile" dello script install.sh:
chmod +x install.sh
per avviare lo script di installazione:
sudo ./install.sh
premendo il tasto Invio confermiamo l'inizio dell'installazione e, alla richiesta, inseriamo la password sysdba.
Lo script di installazione avvia automaticamente systemd-unit firebird-superserver (architettura silenziosa Firebird 3.0). Il servizio Firebird verrà eseguito con parametri predefiniti per il superserver: cache delle pagine di 2048 pagine (per database), buffer di ordinamento di 64 MB (totale) e connessione solo per clienti di terza versione. Visualizzazione dei parametri firebird.conf:
grep -v ^# firebird.conf | grep -v ^$
Si deve tenere presente che i nuovi valori di firebird.conf verranno attivati solo dopo il riavvio del servizio Firebird.
Nella scelta dei valori dei parametri, è importante considerare che ci sono tre principali «consumatori»: la cache delle pagine (per il database), il buffer di ordinamento (totale) e la memoria assegnata dal server per le connessioni dei clienti. È possibile gestire solo i primi due – la quantità di memoria delle connessioni dei clienti dipende dal numero e dal testo delle query memorizzate nella cache, dai loro piani e dagli oggetti del database coinvolti nelle query. La valutazione della memoria delle connessioni dei clienti viene effettuata solo empiricamente e può variare con il cambiamento delle applicazioni client e/o degli oggetti del database.
Per il superserver su host con poca memoria (fino a 12-16 GB), non è consigliabile allocare per la cache delle pagine e per il buffer di ordinamento più di un terzo - un quarto della memoria totale RAM.
Se il numero di database non è fissato e può variare, la quantità totale di memoria della cache delle pagine deve essere divisa per il numero massimo di database che possono essere sul server. La dimensione della cache delle pagine è specificata in pagine e deve essere separatamente convertita in byte.
Per passare all'architettura classica, è necessario, come minimo, specificare esplicitamente ServerMode in firebird.conf, ridurre anche lì la cache delle pagine (non più di 2K), ridurre il buffer di ordinamento (la somma totale consentita di tutti gli ordinamenti, divisa per il numero massimo di connessioni), vietare e fermare il modulo firebird-superserver, consentire e avviare il modulo firebird-classic.socket.
L'uso dell'architettura superclassic in Firebird 3.0 non ha molto senso: la «reliability» – come nel superserver e lo stesso buffer di ordinamento comune. Non c'è cache delle pagine comune e le «perdite» nella sincronizzazione di diverse connessioni tra di loro sono le stesse di quelle classiche.
Si deve ricordare che in Firebird 3.0 parte dei parametri (cache delle pagine, dimensioni del file di blocco, tabelle hash e alcuni altri) possono essere specificati in databases.conf individualmente per ciascun database. È utile, ad esempio, specificare un valore ridotto per il DefaultDbCachePages in firebird.conf e impostare cache per pagina individuali per le basi necessarie in databases.conf.
Per domande riguardanti l'articolo, scrivi nei commenti o invia un'email al nostro indirizzo di supporto support@ibase.ru.
Fonte: habr.com
