[comment]: # ({d4c2e042-97796c37})
# 8 Problemi noti

Vedi anche: [Problemi di compilazione](/manual/installation/known_issues/compilation_issues).

[comment]: # ({/d4c2e042-97796c37})

[comment]: # ({59bf15f1-ac66370d})
#### Problemi noti in 7.0.20

Non è consigliato eseguire l'aggiornamento a questa versione a causa di:

-    problema di improvviso picco della CPU se si utilizza il plugin MySQL di Zabbix agent 2 (vedere [ZBX-27156](https://support.zabbix.com/browse/ZBX-27156))
-    grafico per gli item di Zabbix active agent che mostra un avviso "Undefined array key" a causa di un errore di indice non definito (vedere [ZBX-27153](https://support.zabbix.com/browse/ZBX-27153))

[comment]: # ({/59bf15f1-ac66370d})

[comment]: # ({acc59e29-60337342})
#### Aggiornamento

[comment]: # ({/acc59e29-60337342})

[comment]: # ({4128d758-9dcbc232})
##### Impostazione della modalità SQL per un aggiornamento riuscito

L'impostazione `sql_mode` in MySQL/MariaDB deve avere la modalità "STRICT_TRANS_TABLES" impostata.
Se è assente, l'aggiornamento del database Zabbix non riuscirà (vedere anche [ZBX-19435](https://support.zabbix.com/browse/ZBX-19435)).

[comment]: # ({/4128d758-9dcbc232})

[comment]: # ({62592ed3-5c2a7ea7})
##### Aggiornamento con MariaDB 10.2.1 e versioni precedenti

L'aggiornamento di Zabbix potrebbe non riuscire se le tabelle del database sono state create con MariaDB 10.2.1 o versioni precedenti, perché in tali versioni il formato di riga predefinito è compact.
Questo problema può essere risolto modificando il formato di riga in dynamic (vedere anche [ZBX-17690](https://support.zabbix.com/browse/ZBX-17690)).

[comment]: # ({/62592ed3-5c2a7ea7})

[comment]: # ({468fcd25-284cbce4})
#### Template

[comment]: # ({/468fcd25-284cbce4})

[comment]: # ({fe6574bb-e0ea85e4})
##### Compatibilità dei template negli ambienti dual-stack (IPv4/IPv6)

Negli ambienti dual-stack (sistemi configurati per supportare sia IPv4 sia IPv6), il nome host `localhost` in genere si risolve sia in indirizzi IPv4 sia in indirizzi IPv6.
A causa della comune priorità assegnata a IPv6 rispetto a IPv4 da molti sistemi operativi e resolver DNS, i template di Zabbix potrebbero non funzionare correttamente se il servizio monitorato è configurato per ascoltare solo su IPv4.

I servizi non configurati per ascoltare su indirizzi IPv6 possono diventare inaccessibili, causando errori di monitoraggio.
Gli utenti potrebbero configurare correttamente l'accesso per IPv4, ma continuare a riscontrare problemi di connettività a causa del comportamento predefinito che privilegia IPv6.

Una soluzione alternativa consiste nel verificare che i servizi (Nginx, Apache, PostgreSQL, ecc.) siano configurati per ascoltare sia sugli indirizzi IPv4 sia su quelli IPv6, e che a server/agent di Zabbix sia consentito l'accesso tramite IPv6.
Inoltre, nei template e nelle configurazioni di Zabbix, usare esplicitamente `localhost` invece di `127.0.0.1` per garantire la compatibilità con IPv4 e IPv6.

**Ad esempio**, quando si monitora PostgreSQL con il template [PostgreSQL by Zabbix agent 2](https://git.zabbix.com/projects/ZBX/repos/zabbix/browse/templates/db/postgresql_agent2?at=refs%2Fheads%2Frelease%2F7.0), potrebbe essere necessario modificare il file `pg_hba.conf` per consentire le connessioni per l'utente `zbx_monitor`.
Se l'ambiente dual-stack dà priorità a IPv6 (il sistema risolve `localhost` in `::1`) e si configura `localhost` ma si aggiunge solo una voce IPv4 (`127.0.0.1/32`), la connessione fallirà perché non esiste una voce IPv6 corrispondente.

Il seguente esempio di file `pg_hba.conf` garantisce che l'utente `zbx_monitor` possa connettersi a qualsiasi database dalla macchina locale usando sia indirizzi IPv4 sia IPv6 con metodi di autenticazione diversi:

```ini
# TYPE     DATABASE     USER            ADDRESS          METHOD
  host     all          zbx_monitor     localhost        trust
  host     all          zbx_monitor     127.0.0.1/32     md5
  host     all          zbx_monitor     ::1/128          scram-sha-256
```

Se necessario, è anche possibile usare direttamente l'indirizzo IPv4 (`127.0.0.1`) quando si configura il macro del template [PostgreSQL by Zabbix agent 2](https://git.zabbix.com/projects/ZBX/repos/zabbix/browse/templates/db/postgresql_agent2?at=refs%2Fheads%2Frelease%2F7.0) per la stringa di connessione.

[comment]: # ({/fe6574bb-e0ea85e4})

[comment]: # ({56ece64f-5da64b1a})
#### Installazione accidentale dei pacchetti Zabbix di EPEL

Se il repository EPEL è installato e abilitato, l'installazione dei pacchetti Zabbix potrebbe scaricare le versioni EPEL invece dei pacchetti Zabbix ufficiali.
Per risolvere il problema:

1\. Rimuovere eventuali pacchetti Zabbix installati da EPEL:

```bash
dnf remove zabbix-server-mysql
```

2\. Escludere i pacchetti Zabbix da EPEL aggiungendo la seguente riga al file `/etc/yum.repos.d/epel.repo`:

```ini
[epel]
...
excludepkgs=zabbix*
```

3.\ Reinstallare il pacchetto ufficiale del server Zabbix:

```bash
dnf install zabbix-server-mysql
```

Durante l'installazione, i pacchetti Zabbix ufficiali includono la parola `release` nella loro stringa di versione (ad esempio, `7.0.0-release1.el8`), distinguendosi così dai pacchetti EPEL.

[comment]: # ({/56ece64f-5da64b1a})

[comment]: # ({16623e24-ca1706ae})
#### Pacchetti Zabbix per RHEL in ambienti Red Hat UBI

Quando si installa Zabbix dai pacchetti di Red Hat Enterprise Linux in ambienti [Red Hat Universal Base Image](https://catalog.redhat.com/software/base-images), assicurarsi di avere accesso ai repository e alle dipendenze richiesti.
I pacchetti Zabbix dipendono dalle librerie `libOpenIPMI.so` e `libOpenIPMIposix.so`, che non sono fornite da alcun pacchetto nei repository del gestore pacchetti predefiniti abilitati sui sistemi UBI e causeranno errori di installazione.

Le librerie `libOpenIPMI.so` e `libOpenIPMIposix.so` sono disponibili nel pacchetto `OpenIPMI-libs`, fornito dal repository `redhat-#-for-<arch>-appstream-rpms`.
L'accesso a questo repository è gestito tramite sottoscrizioni che, nel caso degli ambienti UBI, vengono propagate montando nel namespace del file system del container le directory di configurazione dei repository e dei secret dell'host RHEL.

Per ulteriori informazioni, vedere [ZBX-24291](https://support.zabbix.com/browse/ZBX-24291).

[comment]: # ({/16623e24-ca1706ae})

[comment]: # ({ddb884e8-af503946})
#### Chiave di firma scaduta per i pacchetti RHEL

Durante l'aggiornamento di Zabbix su [Red Hat Enterprise Linux](/manual/installation/upgrade/packages/rhel#update-repository-configuration-package) o sulle sue derivate, potresti riscontrare un problema di chiave di firma scaduta per i pacchetti nel [repository Zabbix](https://repo.zabbix.com/zabbix/7.0/).
Quando una chiave di firma scade, i tentativi di verificare le firme dei pacchetti genereranno un errore che indica che il certificato o la chiave non sono più validi.
Ad esempio:

```bash
error: Verifying a signature using certificate D9AA84C2B617479C6E4FCF4D19F2475308EFA7DD (Zabbix LLC (Jul 2022) <packager@zabbix.com>):
  1. Certificate 19F2475308EFA7DD invalid: certificate is not alive
      because: The primary key is not live
      because: Expired on 2024-07-04T11:41:23Z
  2. Key 19F2475308EFA7DD invalid: key is not alive
      because: The primary key is not live
      because: Expired on 2024-07-04T11:41:23Z
```

Per risolvere questi problemi, reinstalla manualmente il pacchetto `zabbix-release` più recente per la tua specifica variante di RHEL (sostituisci il link seguente con quello corretto dal [repository Zabbix](https://repo.zabbix.com/zabbix/7.0/)).

Ad esempio, su **RHEL 9**, esegui:

```bash
rpm -Uvh https://repo.zabbix.com/zabbix/7.0/rhel/9/x86_64/zabbix-release-latest.el9.noarch.rpm
```

Quindi, aggiorna le informazioni del repository:

```bash
dnf update
```

Per ulteriori informazioni, vedi [ZBX-24761](https://support.zabbix.com/browse/ZBX-24761).

[comment]: # ({/ddb884e8-af503946})

[comment]: # ({1247e44f-40e33d04})
#### Connessione TLS al database con MariaDB

La connessione TLS al database non è supportata con l'opzione 'verify\_ca' per il [parametro](/manual/appendix/config/zabbix_server) DBTLSConnect se viene utilizzato MariaDB.

[comment]: # ({/1247e44f-40e33d04})

[comment]: # ({fa488c09-40ea4656})
#### Possibili deadlock con MySQL/MariaDB

Quando si opera con un carico elevato e con più di un worker LLD coinvolto, è possibile incorrere in un deadlock causato da un errore di InnoDB relativo alla strategia di blocco delle righe (vedere [bug upstream](https://github.com/mysql/mysql-server/commit/7037a0bdc83196755a3bf3e935cfb3c0127715d5)).
L'errore è stato corretto in MySQL a partire dalla versione 8.0.29, ma non in MariaDB.
Per maggiori dettagli, vedere [ZBX-21506](https://support.zabbix.com/browse/ZBX-21506).

[comment]: # ({/fa488c09-40ea4656})

[comment]: # ({1ca1b80c-70c19e71})
#### Correlazione globale degli eventi

Gli eventi potrebbero non essere correlati correttamente se l'intervallo di tempo tra il primo e il secondo evento è molto piccolo, cioè mezzo secondo o meno.

[comment]: # ({/1ca1b80c-70c19e71})

[comment]: # ({6c096f65-215c95a7})
#### Intervallo del tipo di dato numerico (float) con PostgreSQL 11 e versioni precedenti

Le versioni di PostgreSQL 11 e precedenti supportano solo un intervallo di valori in virgola mobile di circa -1.34E-154 a 1.34E+154.

[comment]: # ({/6c096f65-215c95a7})

[comment]: # ({782693b6-dfc40df7})
#### NetBSD 8.0 e versioni successive

Vari processi di Zabbix potrebbero arrestarsi in modo casuale all'avvio nelle versioni 8.X e 9.X di NetBSD.  
Ciò è dovuto alla dimensione predefinita troppo ridotta dello stack (4 MB), che deve essere aumentata eseguendo:

```bash
ulimit -s 10240
```

Per ulteriori informazioni, consultare la segnalazione del problema correlata: [ZBX-18275](https://support.zabbix.com/browse/ZBX-18275).

[comment]: # ({/782693b6-dfc40df7})

[comment]: # ({9e6b7b54-ca368d3f})
#### Limitazioni delle espressioni regolari in Zabbix agent 2

Zabbix agent 2 non supporta i lookahead e i lookbehind nelle espressioni regolari a causa delle limitazioni della libreria standard regexp di Go.

[comment]: # ({/9e6b7b54-ca368d3f})

[comment]: # ({153d6a2b-3cf04fe3})
#### Controlli IPMI

I controlli IPMI non funzionano con il pacchetto standard della libreria OpenIPMI su Debian precedenti alla 9 (stretch) e Ubuntu precedenti alla 16.04 (xenial).
Per risolvere il problema, ricompilare la libreria OpenIPMI con OpenSSL abilitato, come descritto in [ZBX-6139](https://support.zabbix.com/browse/ZBX-6139).

[comment]: # ({/153d6a2b-3cf04fe3})

[comment]: # ({4584bdf5-bcfb94d3})
#### IPMI — host non attendibili possono causare il crash di OpenIPMI

Esiste un bug nella libreria OpenIPMI utilizzata da Zabbix per il polling dei dati IPMI che può essere attivato da risposte appositamente create provenienti da un dispositivo non attendibile.  
Un dispositivo IPMI non attendibile può inviare dati manipolati che causano il crash della libreria OpenIPMI, il che a sua volta può causare la terminazione del processo del server Zabbix che esegue il polling IPMI.

[comment]: # ({/4584bdf5-bcfb94d3})

[comment]: # ({aa786b9a-8c5cdd23})
#### Controlli SSH

-   Alcune distribuzioni Linux come Debian e Ubuntu non supportano le chiavi private cifrate (con passphrase) se la libreria libssh2 è installata dai pacchetti.
Per maggiori dettagli, vedere [ZBX-4850](https://support.zabbix.com/browse/ZBX-4850).
-   Quando si utilizza libssh 0.9.x su alcune distribuzioni Linux con OpenSSH 8, i controlli SSH possono occasionalmente segnalare "Cannot read data from SSH server".
Ciò è causato da un [problema](https://gitlab.com/libssh/libssh-mirror/-/merge_requests/101) di libssh ([rapporto più dettagliato](https://bugs.libssh.org/T231)).
Si prevede che l'errore sia stato corretto con una release stabile di libssh 0.9.5.
Per dettagli, vedere anche [ZBX-17756](https://support.zabbix.com/browse/ZBX-17756).
-   L'uso della pipe "|" nello script SSH può causare l'errore "Cannot read data from SSH server".
In questo caso si consiglia di aggiornare la versione della libreria libssh.
Per dettagli, vedere anche [ZBX-21337](https://support.zabbix.com/browse/ZBX-21337).

[comment]: # ({/aa786b9a-8c5cdd23})

[comment]: # ({ce3da609-0c2fc2b9})
#### Controlli ODBC

-   Il driver MySQL unixODBC non dovrebbe essere usato con Zabbix server o Zabbix proxy compilati contro la libreria connettore MariaDB e viceversa; se possibile, è inoltre preferibile evitare di usare lo stesso connettore come driver a causa di un [bug upstream](https://bugs.mysql.com/bug.php?id=73709).
Configurazione consigliata:

    Connettore PostgreSQL, SQLite o Oracle → driver MariaDB o MySQL unixODBC<br>Connettore MariaDB → driver MariaDB unixODBC<br>Connettore MySQL → driver MySQL unixODBC

    Vedere [ZBX-7665](https://support.zabbix.com/browse/ZBX-7665) per ulteriori informazioni e workaround disponibili.

-   I dati XML interrogati da Microsoft SQL Server possono essere troncati in vari modi su sistemi Linux e UNIX.

-   È stato osservato che l'uso dei controlli ODBC per monitorare database Oracle tramite varie versioni di Oracle Instant Client per Linux causa il crash di Zabbix server.<br> 
Vedere anche: [ZBX-18402](https://support.zabbix.com/browse/ZBX-18402), [ZBX-20803](https://support.zabbix.com/browse/ZBX-20803).

-   Se si utilizza il driver FreeTDS UnixODBC, è necessario anteporre un'istruzione 'SET NOCOUNT ON' a una query SQL (ad esempio, ````SET NOCOUNT ON DECLARE @strsql NVARCHAR(max) SET @strsql = ....````).
In caso contrario, l'item di monitoraggio del database in Zabbix non riuscirà a recuperare le informazioni e restituirà l'errore 
"SQL query returned empty result".<br>
Vedere [ZBX-19917](https://support.zabbix.com/browse/ZBX-19917) per ulteriori informazioni.

[comment]: # ({/ce3da609-0c2fc2b9})

[comment]: # ({fa40a989-1db730d3})
#### Parametro del metodo di richiesta errato negli item

Il parametro del metodo di richiesta, utilizzato solo nei controlli HTTP, potrebbe essere impostato in modo errato su '1', un valore non predefinito per tutti gli item come risultato di un aggiornamento da una versione di Zabbix precedente alla 4.0.
Per i dettagli su come correggere questa situazione, vedere [ZBX-19308](https://support.zabbix.com/browse/ZBX-19308).

[comment]: # ({/fa40a989-1db730d3})

[comment]: # ({6b07e4f0-4713dff4})
#### Monitoraggio web e HTTP agent

Zabbix server presenta perdite di memoria su alcune distribuzioni Linux a causa di un [bug upstream](https://bugzilla.redhat.com/show_bug.cgi?id=1057388) quando "SSL verify peer" è abilitato negli scenari web o in HTTP agent.
Per ulteriori informazioni e per le soluzioni alternative disponibili, vedere [ZBX-10486](https://support.zabbix.com/browse/ZBX-10486).

[comment]: # ({/6b07e4f0-4713dff4})

[comment]: # ({5aaa698c-9cd7efe1})
#### Controlli semplici

Esiste un bug nelle versioni di **fping** precedenti alla v3.10 che gestisce in modo errato i pacchetti di risposta echo duplicati.
Ciò può causare risultati inattesi per gli item `icmpping`, `icmppingloss`, `icmppingsec`.
Si consiglia di utilizzare la versione più recente di **fping**.
Per maggiori dettagli, vedere [ZBX-11726](https://support.zabbix.com/browse/ZBX-11726).

[comment]: # ({/5aaa698c-9cd7efe1})

[comment]: # ({7d921240-49c461f1})
#### Errori con l'esecuzione di fping in container rootless

Quando i container sono in esecuzione in modalità rootless o in un ambiente con restrizioni specifiche, durante l'esecuzione di controlli ICMP potresti riscontrare errori relativi all'esecuzione di fping, come `fping: Operation not permitted` oppure la perdita di tutti i pacchetti verso tutte le risorse.

Per risolvere questo problema, aggiungi `--cap-add=net_raw` ai comandi "docker run" o "podman run".

Inoltre, l'esecuzione di fping in ambienti non root può richiedere una modifica di sysctl, ad esempio: 

```bash
sudo sysctl -w "net.ipv4.ping_group_range=0 1995"
```

dove "1995" è il GID di zabbix.
Per maggiori dettagli, vedi [ZBX-22833](https://support.zabbix.com/browse/ZBX-22833).

[comment]: # ({/7d921240-49c461f1})

[comment]: # ({4356fdf8-a4574c73})
#### Controlli SNMP

Se viene utilizzato il sistema operativo OpenBSD, un bug di tipo use-after-free nella libreria Net-SNMP fino alla versione 5.7.3 può causare un arresto anomalo di Zabbix server se il parametro SourceIP è impostato nel file di configurazione di Zabbix server.
Come soluzione alternativa, non impostare il parametro SourceIP.
Lo stesso problema si applica anche a Linux, ma non causa l'interruzione del funzionamento di Zabbix server.
Una patch locale per il pacchetto net-snmp su OpenBSD è stata applicata e verrà rilasciata con OpenBSD 6.3.

[comment]: # ({/4356fdf8-a4574c73})

[comment]: # ({4cdd7794-d699f9d6})
#### Picchi nei dati SNMP

Sono stati osservati picchi nei dati SNMP che potrebbero essere correlati a determinati fattori fisici, come sbalzi di tensione nella rete elettrica.
Per maggiori dettagli, vedere [ZBX-14318](https://support.zabbix.com/browse/ZBX-14318).

[comment]: # ({/4cdd7794-d699f9d6})

[comment]: # ({219609d4-7aeb682d})
#### Trap SNMP

Il pacchetto "net-snmp-perl", necessario per le trap SNMP, è stato rimosso in RHEL 8.0-8.2; reintrodotto in RHEL 8.3.

Quindi, se si utilizza RHEL 8.0-8.2, la soluzione migliore è eseguire l'aggiornamento a RHEL 8.3.

Per ulteriori informazioni, consultare anche [ZBX-17192](https://support.zabbix.com/browse/ZBX-17192).

[comment]: # ({/219609d4-7aeb682d})

[comment]: # ({9a52cca5-f46cb486})
#### Arresto anomalo del processo alerter in RHEL 7

Sono stati riscontrati casi di arresto anomalo di un processo alerter di Zabbix server in RHEL 7.
Per i dettagli, vedere [ZBX-10461](https://support.zabbix.com/browse/ZBX-10461).

[comment]: # ({/9a52cca5-f46cb486})

[comment]: # ({e54095e6-e9907d15})
#### Aggiornamento di Zabbix agent 2 (6.0.5 o versioni precedenti)

Durante l'aggiornamento di Zabbix agent 2 (versione 6.0.5 o precedente) dai pacchetti, potrebbe verificarsi un errore di conflitto dei file relativo ai plugin.
Per risolvere l'errore, eseguire un backup della configurazione di agent 2 (se necessario), disinstallare agent 2 e installarlo nuovamente.

Sui sistemi basati su RHEL, eseguire:

```bash
dnf remove zabbix-agent2
dnf install zabbix-agent2
```

Sui sistemi basati su Debian, eseguire:

```bash
apt remove zabbix-agent2
apt install zabbix-agent2
```

Per ulteriori informazioni, vedere [ZBX-23250](https://support.zabbix.com/browse/ZBX-23250).

[comment]: # ({/e54095e6-e9907d15})

[comment]: # ({70349327-6e1fb8fe})
#### Cambio casuale delle impostazioni locali del frontend

È stato osservato che le impostazioni locali del frontend possono cambiare senza una logica apparente, cioè alcune pagine (o parti di pagine) vengono visualizzate in una lingua, mentre altre pagine (o parti di pagine) in una lingua diversa.
In genere il problema può comparire quando ci sono diversi utenti, alcuni dei quali usano una locale, mentre altri ne usano un'altra.

Una soluzione alternativa nota consiste nel disabilitare il multithreading in PHP e Apache.

Il problema è legato al modo in cui l'impostazione della locale funziona [in PHP](https://www.php.net/manual/en/function.setlocale): le informazioni sulla locale vengono mantenute per processo, non per thread.
Quindi, in un ambiente multithread, quando ci sono diversi progetti eseguiti dallo stesso processo Apache, è possibile che la locale venga modificata in un altro thread e che ciò cambi il modo in cui i dati possono essere elaborati nel thread di Zabbix.

Per ulteriori informazioni, vedere le segnalazioni di problema correlate:

-   [ZBX-10911](https://support.zabbix.com/browse/ZBX-10911) (Problema con il cambio casuale delle impostazioni locali del frontend)
-   [ZBX-16297](https://support.zabbix.com/browse/ZBX-16297) (Problema con l'elaborazione dei numeri nei grafici che utilizzano la funzione `bcdiv` delle funzioni BC Math)

[comment]: # ({/70349327-6e1fb8fe})

[comment]: # ({7925147c-4f3b73ce})
#### Grafici

##### Problemi con i grafici (classici)

Se riscontri problemi con i grafici classici, si consiglia di aggiornare la libreria GD (libgd) alla versione 2.3.3-13 o successiva, e PHP alla versione 8.0.19, 8.1.33, 8.2.29, 8.3.25, 8.4.12 o successiva.

##### Ora legale

Le modifiche all'ora legale (DST) comportano irregolarità nella visualizzazione delle etichette dell'asse X (duplicazione della data, data mancante, ecc.).

##### Aggregazione sum

Quando si utilizza l'[aggregazione sum](/manual/config/visualization/graphs/aggregate#configuration) in un grafico per un periodo inferiore a un'ora, i grafici mostrano valori errati (moltiplicati) quando i dati provengono dai trend.

##### Sovrapposizione del testo

Per alcune lingue del frontend (ad esempio il giapponese), i font locali possono causare la sovrapposizione del testo nella legenda del grafico.
Per evitare questo problema, utilizzare la versione 2.3.0 (o successiva) dell'estensione PHP GD.

[comment]: # ({/7925147c-4f3b73ce})

[comment]: # ({d77e6a97-357fdb5b})
#### Monitoraggio dei file di log

Gli item `log[]` e `logrt[]` rileggono ripetutamente il file di log dall'inizio se il file system è pieno al 100% e il file di log viene aggiornato in append (vedere [ZBX-10884](https://support.zabbix.com/browse/ZBX-10884) per ulteriori informazioni).

[comment]: # ({/d77e6a97-357fdb5b})

[comment]: # ({726d79e5-82ff58c2})
#### Query MySQL lente

Il server Zabbix genera query `SELECT` lente in caso di valori inesistenti per gli item.
Questo [problema](https://bugs.mysql.com/bug.php?id=74602) è noto nelle versioni MySQL 5.6/5.7 (per una discussione più estesa, vedere [ZBX-10652](https://support.zabbix.com/browse/ZBX-10652)) e, in casi specifici, può verificarsi anche nelle versioni MySQL successive.
Una soluzione alternativa consiste nel disabilitare l'ottimizzatore [`index_condition_pushdown`](https://dev.mysql.com/doc/refman/8.0/en/switchable-optimizations.html#optflag_index-condition-pushdown) o [`prefer_ordering_index`](https://dev.mysql.com/doc/refman/8.0/en/switchable-optimizations.html#optflag_prefer-ordering-index) in MySQL.
Si noti, tuttavia, che questa soluzione alternativa potrebbe non risolvere tutti i problemi relativi alle query lente.

[comment]: # ({/726d79e5-82ff58c2})

[comment]: # ({4271402d-7ed39efb})
#### Sincronizzazione lenta della configurazione con Oracle

La sincronizzazione della configurazione può essere lenta nelle installazioni Zabbix con database Oracle che hanno un numero elevato di item e di fasi di preprocessing degli item.
Ciò è causato dalla velocità del motore del database Oracle nell'elaborazione dei campi di tipo *nclob*.

Per migliorare le prestazioni, è possibile convertire i tipi di campo da *nclob* a *nvarchar2* applicando manualmente la patch del database [items_nvarchar_prepare.sql](/../assets/en/manual/installation/items_nvarchar_prepare.sql).
Si noti che questa conversione ridurrà il limite massimo della dimensione del campo da 65535 byte a 4000 byte per i parametri di preprocessing degli item e per i parametri degli item, come *Description*, il campo *Script* dell'item Script, i campi *Request body* e *Headers* dell'item HTTP agent, e il campo *SQL query* dell'item Database monitor.
Le query per determinare i nomi dei template che devono essere eliminati prima di applicare la patch sono fornite nella patch come commento.
In alternativa, se MAX_STRING_SIZE è impostato, è possibile modificare *nvarchar2(4000)* in *nvarchar2(32767)* nelle query della patch per impostare il limite della dimensione del campo a 32767 byte.

Per una discussione più approfondita, vedere [ZBX-22363](https://support.zabbix.com/browse/ZBX-22363).

[comment]: # ({/4271402d-7ed39efb})

[comment]: # ({7b21750b-e6d094e6})
#### Impostazioni del filtro persistenti dai link

Quando si apre un link a una pagina del frontend di Zabbix che contiene impostazioni del filtro, incluso il selettore temporale, il filtro viene automaticamente salvato nel database per l'utente, sostituendo il filtro e/o le impostazioni del selettore temporale precedentemente salvati per quella pagina.
Queste impostazioni rimangono attive finché l'utente non le aggiorna o reimposta manualmente.

[comment]: # ({/7b21750b-e6d094e6})

[comment]: # ({7e8483c4-17c4463f})
#### Problema con l'indirizzo IPv6 nelle trap SNMPv3

A causa di un bug di net-snmp, l'indirizzo IPv6 potrebbe non essere visualizzato correttamente quando si utilizza SNMPv3 nelle trap SNMP.
Per maggiori dettagli e una possibile soluzione alternativa, vedere [ZBX-14541](https://support.zabbix.com/browse/ZBX-14541).

[comment]: # ({/7e8483c4-17c4463f})

[comment]: # ({ca8e0df9-d77627ce})
#### Indirizzo IP IPv6 lungo troncato nelle informazioni di accesso non riuscito

Un messaggio di tentativo di accesso non riuscito visualizzerà solo i primi 39 caratteri di un indirizzo IP memorizzato, poiché questo è il limite di caratteri del campo nel database.
Ciò significa che gli indirizzi IP IPv6 più lunghi di 39 caratteri verranno mostrati in modo incompleto.

[comment]: # ({/ca8e0df9-d77627ce})

[comment]: # ({e11e57ad-57420738})
#### Controlli di Zabbix agent su Windows

Le voci DNS inesistenti nel parametro `Server` del file di configurazione di Zabbix agent (zabbix\_agentd.conf) possono aumentare il tempo di risposta di Zabbix agent su Windows.
Questo accade perché il demone di caching DNS di Windows non memorizza nella cache le risposte negative per gli indirizzi IPv4.
Tuttavia, per gli indirizzi IPv6 le risposte negative vengono memorizzate nella cache, quindi una possibile soluzione alternativa consiste nel disabilitare IPv4 sull'host.

[comment]: # ({/e11e57ad-57420738})

[comment]: # ({a4766858-40001075})
#### Esportazione/importazione YAML

Esistono alcuni problemi noti con l'[esportazione/importazione](/manual/xml_export_import) YAML:

-   I messaggi di errore non sono traducibili;
-   JSON valido con estensione di file .yaml a volte non può essere importato;
-   Le date leggibili dall'uomo non racchiuse tra virgolette vengono convertite automaticamente in timestamp Unix.

[comment]: # ({/a4766858-40001075})

[comment]: # ({d08dcd7b-fcbf4bce})
#### Procedura guidata di configurazione su SUSE con NGINX e php-fpm

La procedura guidata di configurazione del frontend non riesce a salvare il file di configurazione su SUSE con NGINX + php-fpm.  
Ciò è causato da un'impostazione nell'unità /usr/lib/systemd/system/php-fpm.service, che impedisce a Zabbix di scrivere in /etc. (introdotta in [PHP 7.4](https://bugs.php.net/bug.php?id=72510)).

Sono disponibili due soluzioni alternative:

-   Impostare l'opzione [ProtectSystem](https://www.freedesktop.org/software/systemd/man/systemd.exec.html#ProtectSystem=) su 'true' invece di 'full' nell'unità systemd di php-fpm.
-   Salvare manualmente il file /etc/zabbix/web/zabbix.conf.php.

[comment]: # ({/d08dcd7b-fcbf4bce})

[comment]: # ({48a90962-b776ce1f})
#### Inoltro dell'header Authorization

In alcuni casi, Apache o NGINX possono impedire che l'header Authorization nelle richieste API raggiunga Zabbix.
Questo può causare problemi di autenticazione quando si utilizza Zabbix API o servizi di single sign-on (SSO), come SAML con Okta.

Per risolvere il problema, aggiorna la configurazione del tuo web server.

Per **Apache**, se lo stai usando come reverse proxy (configurazione non CGI), aggiungi la seguente direttiva a `/etc/httpd/conf/httpd.conf` (nei sistemi basati su RHEL) oppure a `/etc/apache2/apache2.conf` (su Debian/Ubuntu):

```ini
SetEnvIfNoCase ^Authorization$ "(.+)" HTTP_AUTHORIZATION=$1
```

Se Apache esegue direttamente gli script per gestire le richieste (ad esempio, usando mod\_cgi), aggiungi invece la seguente direttiva:

```ini
CGIPassAuth On
```

Al contrario, **NGINX** gestisce automaticamente l'header Authorization.
Tuttavia, se NGINX agisce come reverse proxy, puoi inoltrare esplicitamente l'header Authorization aggiungendo le seguenti direttive a `/etc/nginx/nginx.conf` (per la posizione del tuo frontend Zabbix):

```ini
...
location / {
...
    proxy_set_header Authorization $http_authorization;
    proxy_pass http://backend_server;
...
}
```

Dopo aver aggiornato la configurazione, riavvia il tuo web server.

Per ulteriori dettagli, consulta:

-   [ZBX-22952](https://support.zabbix.com/browse/ZBX-22952)
-   [Apache 2.4 + PHP-FPM and Authorization headers](https://stackoverflow.com/questions/17018586/apache-2-4-php-fpm-and-authorization-headers)
-   Le direttive [SetEnvIfNoCase](https://httpd.apache.org/docs/2.4/mod/mod_setenvif.html#setenvifnocase) e [CGIPassAuth](https://httpd.apache.org/docs/2.4/mod/core.html#CGIPassAuth)
-   [NGINX Reverse Proxy](https://docs.nginx.com/nginx/admin-guide/web-server/reverse-proxy/)

[comment]: # ({/48a90962-b776ce1f})

[comment]: # ({862e7b88-8009b04b})
#### Chromium per il servizio web Zabbix su Ubuntu 20

Sebbene nella maggior parte dei casi il servizio web Zabbix possa essere eseguito con Chromium, su Ubuntu 20.04 l'uso di Chromium provoca il seguente errore:

```default
Cannot fetch data: chrome failed to start:cmd_run.go:994:
WARNING: cannot create user data directory: cannot create 
"/var/lib/zabbix/snap/chromium/1564": mkdir /var/lib/zabbix: permission denied
Sorry, home directories outside of /home are not currently supported. See https://forum.snapcraft.io/t/11209 for details.
```

Questo errore si verifica perché `/var/lib/zabbix` viene utilizzata come directory home dell'utente 'zabbix'.

[comment]: # ({/862e7b88-8009b04b})

[comment]: # ({d669982d-1f99c5d8})
#### Codici di errore personalizzati MySQL

Quando Zabbix rileva che il database di backend non è accessibile, invia una notifica e continua a tentare la connessione.
Per alcuni motori di database, vengono riconosciuti codici di errore specifici.
In MySQL, questi codici di errore riconosciuti includono:

-   CR\_CONN\_HOST\_ERROR
-   CR\_SERVER\_GONE\_ERROR
-   CR\_CONNECTION\_ERROR
-   CR\_SERVER\_LOST
-   CR\_UNKNOWN\_HOST
-   ER\_SERVER\_SHUTDOWN
-   ER\_ACCESS\_DENIED\_ERROR
-   ER\_ILLEGAL\_GRANT\_FOR\_TABLE
-   ER\_TABLEACCESS\_DENIED\_ERROR
-   ER\_UNKNOWN\_ERROR

Inoltre, quando si utilizza Zabbix con un'installazione MySQL su Azure, nei log di Zabbix può comparire il messaggio di errore generico *\[9002\] Some errors occurred*.
Questo messaggio viene inviato dal database al server o al proxy Zabbix.
Per determinare la causa dell'errore, consultare i log di Azure.

[comment]: # ({/d669982d-1f99c5d8})

[comment]: # ({1ecb446e-eb422070})
#### Espressioni regolari non valide dopo il passaggio a PCRE2

In Zabbix 6.0 è stato aggiunto il supporto per PCRE2.  
Anche se PCRE è ancora supportato, i pacchetti di installazione di Zabbix per RHEL 7 e versioni successive, SLES (tutte le versioni), Debian 9 e versioni successive, Ubuntu 16.04 e versioni successive sono stati aggiornati per utilizzare PCRE2.  
Pur offrendo numerosi vantaggi, il passaggio a PCRE2 può causare l'invalidità di alcuni pattern regexp PCRE esistenti o un comportamento differente.  
In particolare, questo riguarda il pattern *\^[\\w-\\.]*.  
Per rendere nuovamente valida questa regexp senza alterarne la semantica, modificare l'espressione in *\^[-\\w\\.]* .  
Ciò accade perché PCRE2 tratta il trattino come un delimitatore, creando un intervallo all'interno di una classe di caratteri.

[comment]: # ({/1ecb446e-eb422070})

[comment]: # ({17e0a154-093b78e2})
#### Errore del widget Geomap

Le mappe nel widget Geomap potrebbero non caricarsi correttamente se hai eseguito l'upgrade da una versione precedente di Zabbix con NGINX e non sei passato al nuovo file di configurazione NGINX durante l'aggiornamento.

Per risolvere il problema, puoi eliminare il vecchio file di configurazione, usare il file di configurazione del pacchetto della versione corrente e riconfigurarlo come descritto nelle [istruzioni di download](https://www.zabbix.com/download?zabbix=6.0&os_distribution=red_hat_enterprise_linux&os_version=8&db=mysql&ws=nginx) nella sezione *e. Configure PHP for Zabbix frontend*.

In alternativa, puoi modificare manualmente un file di configurazione NGINX esistente (in genere, */etc/zabbix/nginx.conf*).
Per farlo, apri il file e individua il seguente blocco:

```ini
location ~ /(api\/|conf[^\.]|include|locale|vendor) {
        deny            all;
        return          404;
}
```

Quindi, sostituisci questo blocco con:

```ini
location ~ /(api\/|conf[^\.]|include|locale) {
        deny            all;
        return          404;
}

location /vendor {
        deny            all;
        return          404;
}
```

[comment]: # ({/17e0a154-093b78e2})

[comment]: # ({f73f4f1f-4654fb6f})
#### Preprocessing — le variabili globali non sono sicure

Il JavaScript di preprocessing viene eseguito per ogni richiesta, ma le assegnazioni a identificatori non dichiarati (ad esempio `secret = value`) creano globali implicite che possono persistere oltre l'esecuzione corrente.
Memorizzare dati sensibili (token, password, ecc.) in globali implicite aumenta il rischio di esposizione accidentale o di riutilizzo da parte di esecuzioni di preprocessing successive o di altre integrazioni che operano nello stesso ambiente.

Non fare affidamento sulle globali implicite.
Dichiara sempre le variabili con `var` o `const` e evita di associare segreti a oggetti globali (ad esempio `globalThis` o `window`).
Non esiste un modo supportato per sovrascrivere gli oggetti globali integrati dall'interno del preprocessing.

Esempio sicuro:

```javascript
var apiToken = payload.token;
var count = 1;
return JSON.stringify({ token: apiToken, calls: count });
```

[comment]: # ({/f73f4f1f-4654fb6f})

[comment]: # ({3a50967e-d2d024db})
#### Crash del server con TimescaleDB dopo l'aggiornamento da 7.0

L'aggiornamento a Zabbix 7.0.1 (o versioni successive) da Zabbix 7.0.0 con TimescaleDB provoca il crash del server.
Questo problema è causato da una soluzione temporanea a un problema del job di compressione nella tabella auditlog in Zabbix 7.0, che ha modificato in modo irreversibile la policy di compressione della tabella auditlog.

Per risolvere il problema, eseguire una ricostruzione manuale della tabella auditlog.
La tabella auditlog difettosa può essere rilevata con questa query:

```default
SELECT config FROM timescaledb_information.jobs WHERE application_name LIKE 'Compression%' AND hypertable_schema='public' AND hypertable_name='auditlog';.
```

Se restituisce un oggetto JSON contenente la proprietà `compress_after` (ad esempio {"hypertable_id": 14, "compress_after": 612000}) allora è necessario ricostruire la tabella.

:::noteimportant
Assicurarsi che Zabbix server sia almeno alla versione 7.0.1rc2 (o successiva); in caso contrario, imposterà di nuovo la policy di compressione errata.
Inoltre, arrestare Zabbix server prima di eseguire lo script e verificare che `auditlog` sia di proprietà dell'utente *zabbix*.
:::

Il modo più semplice per ricostruire la tabella auditlog è:

```sql
CREATE TABLE auditlog_tmp (
	LIKE auditlog INCLUDING DEFAULTS INCLUDING CONSTRAINTS INCLUDING INDEXES
);

SELECT create_hypertable('auditlog_tmp', 'auditid', chunk_time_interval => 604800,
		time_partitioning_func => 'cuid_timestamp', migrate_data => true, if_not_exists => true);

WITH moved_rows AS (
	DELETE FROM auditlog
	RETURNING *
)
INSERT INTO auditlog_tmp
SELECT * FROM moved_rows;

DROP TABLE auditlog;
ALTER TABLE auditlog_tmp RENAME TO auditlog;
```

Vedere anche la [documentazione di TimescaleDB](https://docs.timescale.com/self-hosted/latest/migration/same-db/) per modi più ottimizzati di migrare i dati.

:::noteclassic
Poiché il timestamp richiesto per la partizione viene estratto dal campo `auditid` con una funzione personalizzata, le procedure di supporto usate per la migrazione dei dati da timescaledb-extras non funzioneranno.
:::

[comment]: # ({/3a50967e-d2d024db})

[comment]: # ({3f0c39a4-0049c3e1})
#### Errore di ripristino del database con PostgreSQL/TimescaleDB dopo l'aggiornamento da 7.0.0-7.0.4

L'uso di [`pg_restore`](https://www.postgresql.org/docs/current/app-pgrestore.html) per ripristinare un backup PostgreSQL o TimescaleDB creato in Zabbix 7.0.0-7.0.4 comporterà un errore relativo alla funzione `base36_decode` mancante, causando il fallimento del ripristino:

```sql
ERROR:  function base36_decode(text) does not exist
LINE 1: CAST(base36_decode(substring(cuid FROM 2 FOR 8))/1000 AS int...
             ^
HINT:  No function matches the given name and argument types. You might need to add explicit type casts.
```

Questo errore si verifica durante il ripristino di un backup creato con [`pg_dump`](https://www.postgresql.org/docs/current/app-pgdump.html).

Per risolvere il problema, sostituire la funzione `cuid_timestamp` nel database Zabbix **prima** di creare il backup (si consiglia di arrestare PostgreSQL/TimescaleDB prima di eseguire lo script):

```sql
CREATE OR REPLACE FUNCTION cuid_timestamp(cuid varchar(25)) RETURNS integer AS $$
DECLARE
    base36 varchar;
    a char[];
    ret bigint;
    i int;
    val int;
    chars varchar;
BEGIN
    base36 := substring(cuid FROM 2 FOR 8);

    chars := '0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ';

    FOR i IN REVERSE char_length(base36)..1 LOOP
        a := a || substring(upper(base36) FROM i FOR 1)::char;
    END LOOP;
    i := 0;
    ret := 0;
    WHILE i < (array_length(a, 1)) LOOP
        val := position(a[i + 1] IN chars) - 1;
        ret := ret + (val * (36 ^ i));
        i := i + 1;
    END LOOP;

    RETURN CAST(ret/1000 AS integer);
END;
$$ LANGUAGE 'plpgsql' IMMUTABLE;
DROP FUNCTION IF EXISTS base36_decode(character varying);
```

Vedi anche [ZBX-24955](https://support.zabbix.com/browse/ZBX-24955) (per ulteriori dettagli sull'errore) e la [documentazione di TimescaleDB](https://docs.timescale.com/self-hosted/latest/backup-and-restore/) (per ulteriori opzioni di backup e ripristino).

[comment]: # ({/3f0c39a4-0049c3e1})

[comment]: # ({3cc25c44-9701964f})
#### Gruppi di processori su Windows {#win-proc-groups}

La documentazione Microsoft indica che i sistemi con meno di 64 processori logici hanno sempre un singolo gruppo di processori, Group 0.
Tuttavia, gli utenti di Zabbix hanno segnalato un raro bug [ZBX-20260](https://support.zabbix.com/browse/ZBX-20260), in cui sono presenti due gruppi di processori su sistemi con 64 o meno processori logici.
Ciò ha comportato la presenza dei contatori di prestazioni "\Processor(n)" solo per uno dei due gruppi di processori.
La causa principale effettiva di questo bug non è nota.
Tuttavia, un caso simile è stato descritto su [stackoverflow.com](https://stackoverflow.com/questions/28098082/unable-to-use-more-than-one-processor-group-for-my-threads-in-a-c-sharp-app), e la causa principale in quel caso era nell'interoperabilità tra BIOS e Windows.

[comment]: # ({/3cc25c44-9701964f})

[comment]: # ({b8259264-e9a9a589})
#### Limiti del filtraggio con le collazioni utf8mb4

I filtri (ad esempio, in *Raccolta dati* > [*Manutenzione*](/manual/web_interface/frontend_sections/data_collection/maintenance#using-filter)) potrebbero non funzionare correttamente quando vengono applicati a entità contenenti determinati caratteri Unicode (ad esempio, ȼ, ɇ).
Questo problema deriva dal modo in cui la collazione predefinita utf8mb4\_bin per i database MySQL o MariaDB gestisce l'ordinamento e il confronto dei caratteri Unicode.

Per risolvere questa limitazione, gli utenti possono modificare la collazione delle colonne del database con alternative come utf8mb4\_0900\_bin, utf8mb4\_0900\_ai\_ci o utf8mb4\_unicode\_520\_ci.
Si noti, tuttavia, che la modifica della collazione può causare un comportamento imprevisto nella gestione degli spazi vuoti, oltre che nell'ordinamento e nel filtraggio di altri caratteri.

Per ulteriori informazioni sulla modifica delle collazioni, vedere la [documentazione MySQL](https://dev.mysql.com/doc/refman/8.4/en/alter-table.html#alter-table-character-set) o la [documentazione MariaDB](https://mariadb.com/kb/en/alter-database/).
Per i dettagli sulle differenze tra collazioni, vedere [Unicode Character Sets](https://dev.mysql.com/doc/refman/8.4/en/charset-unicode-sets.html) nella documentazione MySQL.

[comment]: # ({/b8259264-e9a9a589})

[comment]: # ({ef04ad04-6555f84a})
#### Informazioni errate dai gruppi host nidificati nelle mappe

Le informazioni provenienti dai gruppi host nidificati vengono visualizzate in modo errato nelle mappe, ad esempio:

-   L'etichetta del gruppo host mostra il riepilogo del problema senza includere tutti gli host nei gruppi host nidificati;
-   La vista "Host group elements" non mostra un elemento mappa separato per ciascun host nei gruppi host nidificati;
-   L'etichetta della mappa mostra il riepilogo di tutti i problemi senza includere quelli nei gruppi host nidificati.

[comment]: # ({/ef04ad04-6555f84a})

[comment]: # ({6be27fed-bc1758f9})
#### Override delle regole LLD danneggiate in 7.0.7

Nella versione 7.0.7, il server Zabbix si arresta in modo anomalo durante l'elaborazione delle [override](/manual/discovery/low_level_discovery#override) della regola di discovery a basso livello.
Come soluzione temporanea, disabilitare le regole LLD che contengono override.
Il problema è stato corretto in Zabbix 7.0.8rc2.

[comment]: # ({/6be27fed-bc1758f9})

[comment]: # ({40c5a82b-fd33c026})
#### Problema di prestazioni del manager di preprocessing in Zabbix 7.0.14

Nella versione 7.0.14, il manager di preprocessing di Zabbix [preprocessing](/manual/config/items/preprocessing) può causare un elevato utilizzo della CPU quando vengono ricevuti contemporaneamente più valori per un singolo item (ad esempio durante il monitoraggio dei log) e sono configurati più worker di preprocessing.
Come soluzione temporanea, impostare il parametro di configurazione `StartPreprocessors` di [server](/manual/appendix/config/zabbix_server#startpreprocessors)/[proxy](/manual/appendix/config/zabbix_proxy#startpreprocessors) su `1`.
Il problema è stato risolto in Zabbix 7.0.15.

[comment]: # ({/40c5a82b-fd33c026})

[comment]: # ({7fd01df7-0b2a4404})
#### Funzioni macro

Le funzioni macro non funzionano nei parametri degli item script e nei parametri degli script degli item browser.
Corretto in Zabbix 7.0.7.

[comment]: # ({/7fd01df7-0b2a4404})

[comment]: # ({32be743a-08e30174})
#### Accesso agli elementi dell'interfaccia utente con MariaDB 10.5.1-10.5.9

L'accesso al frontend web di Zabbix con un ruolo diverso da Super Admin può causare il messaggio: "System error occurred.
Please contact Zabbix administrator.".
Questo problema interessa le installazioni che utilizzano [versioni di MariaDB](/manual/installation/requirements#third-party-external-surrounding-software) dalla 10.5.1 alla 10.5.9.

Per evitare questo problema, aggiorna MariaDB a una versione successiva alla 10.5.9.
Per ulteriori dettagli, consulta [ZBX-25746](https://support.zabbix.com/browse/ZBX-25746).

[comment]: # ({/32be743a-08e30174})

[comment]: # ({1b095acd-a2d54ba5})
#### Profilazione dell'uso eccessivo di memoria con tcmalloc

Se sospetti che la tua installazione di Zabbix stia usando troppa memoria, puoi utilizzare la funzionalità di profilazione della memoria di [tcmalloc](https://github.com/google/tcmalloc) per analizzare il consumo di memoria di Zabbix server/proxy.

1\. Quando installi Zabbix [dai sorgenti](/manual/installation/install#configure-the-sources), configura i flag aggiuntivi:

```bash
export CFLAGS="-std=gnu99 -g -O0"
```

Il flag `-std=gnu99` è richiesto per compilare Zabbix server, Zabbix proxy o Zabbix agent.
Il flag `-g` aggiunge informazioni di debug aggiuntive, mentre `-O0` disabilita le ottimizzazioni, che possono interferire con la profilazione di tcmalloc.

2\. Imposta le seguenti variabili d'ambiente prima di avviare Zabbix server.
Queste variabili indicano a tcmalloc come tracciare e segnalare l'utilizzo della memoria:

```bash
LD_PRELOAD="/usr/lib/aarch64-linux-gnu/libtcmalloc.so" \
HEAPPROFILE=./heap_profile \
HEAP_PROFILE_ALLOCATION_INTERVAL=0 \
HEAP_PROFILE_INUSE_INTERVAL=4294967296 \
HEAPPROFILESIGNAL=5 \
MALLOCSTATS=1 \
./sbin/zabbix_server -f -c /etc/zabbix/zabbix_server.conf
```

3\. Genera un dump del profilo inviando il segnale 5 al processo di destinazione.
Sostituisci 1234 con l'ID reale del processo (PID):

```bash
kill -5 1234
```

4\. Stampa il profilo generato:

```bash
pprof-symbolize -text ./sbin/zabbix_server ./heap_profile.0001.heap

Using local file ./sbin/zabbix_server.
Using local file ./heap_profile.0001.heap.
Total: 1078.1 MB
  1076.8  99.9%  99.9%   1076.8  99.9% zbx_malloc2
     1.0   0.1% 100.0%      1.0   0.1% __GI___strdup
     0.2   0.0% 100.0%      0.2   0.0% CRYPTO_zalloc@@OPENSSL_3.0.0
     0.1   0.0% 100.0%      0.1   0.0% OPENSSL_LH_insert@@OPENSSL_3.0.0
     0.0   0.0% 100.0%      0.0   0.0% zbx_realloc2
     0.0   0.0% 100.0%      0.1   0.0% PKCS7_decrypt@@OPENSSL_3.0.0
     0.0   0.0% 100.0%      0.0   0.0% find_best_tree_node
     0.0   0.0% 100.0%      0.0   0.0% CRYPTO_strndup@@OPENSSL_3.0.0
     ...
     0.0   0.0% 100.0%      0.0   0.0% preprocessing_flush_value
     0.0   0.0% 100.0%   1074.0  99.6% preprocessor_add_request
```

In questo esempio, zbx\_malloc2 è responsabile di quasi tutte le allocazioni di memoria.

Vedi anche:

-   [ZBX-25050](https://support.zabbix.com/browse/ZBX-25050) e [ZBX-25584](https://support.zabbix.com/browse/ZBX-25584) per i relativi report del problema.
-   [GCC Option Summary](https://gcc.gnu.org/onlinedocs/gcc-14.2.0/gcc/Option-Summary.html) per le opzioni di compilazione (`-std=gnu99`, `-g`, `-O0`, ecc.).
-   la documentazione di [Gperftools Heap Profiler](https://gperftools.github.io/gperftools/heapprofile.html) sulle variabili d'ambiente per la profilazione di tcmalloc.

[comment]: # ({/1b095acd-a2d54ba5})

[comment]: # ({c40b2ad1-265a3af4})
#### MySQL 8.0 Group Replication in modalità multi-primary

Quando si utilizza MySQL 8.0 Group Replication in modalità multi-primary, durante il commit delle transazioni si può riscontrare un errore simile al seguente:

```default
1531697:20250128:064734.697 query [txnlev:1] [update alerts set status=1,retries=0,error='' where alertid=154618;
1531697:20250128:064734.713 query [txnlev:1] [commit;]
1531697:20250128:064734.753 [Z3005] query failed: [3101] Plugin instructed the server to rollback the current transaction. [commit;]
```

Questo errore sembra essere causato da problemi nelle operazioni di rollback che coinvolgono vincoli di chiave esterna.

Vedi anche:

-   [ZBX-26060](https://support.zabbix.com/browse/ZBX-26060) per il relativo report del problema.
-   [MySQL Bug #96758 "Rollbacks with Foreign Keys on single node"](https://bugs.mysql.com/bug.php?id=96758) per il problema a monte.

[comment]: # ({/c40b2ad1-265a3af4})
