Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

# synch/mutex/innodb/fil\$1sistema\$1mutex
<a name="ams-waits.innodb-fil-system-mutex"></a>

L’evento `synch/mutex/innodb/fil_system_mutex` si verifica quando una sessione è in attesa di accedere alla cache di memoria tablespace.

**Topics**
+ [Versioni del motore supportate](#ams-waits.innodb-fil-system-mutex.context.supported)
+ [Contesto](#ams-waits.innodb-fil-system-mutex.context)
+ [Probabili cause di aumento delle attese](#ams-waits.innodb-fil-system-mutex.causes)
+ [Azioni](#ams-waits.innodb-fil-system-mutex.actions)

## Versioni del motore supportate
<a name="ams-waits.innodb-fil-system-mutex.context.supported"></a>

Queste informazioni sull'evento di attesa sono supportate per le seguenti versioni del motore:
+ Aurora MySQL versioni 2 e 3

## Contesto
<a name="ams-waits.innodb-fil-system-mutex.context"></a>

InnoDB utilizza tablespace per gestire l'area di archiviazione per tabelle e file di registro. La *cache di memoria di tablespace* è una struttura di memoria globale che mantiene le informazioni sulle tablespace. MySQL utilizza attese `synch/mutex/innodb/fil_system_mutex` per controllare l'accesso simultaneo alla cache di memoria di tablespace. 

L'evento `synch/mutex/innodb/fil_system_mutex` indica che attualmente esistono più operazioni che devono recuperare e manipolare le informazioni nella cache di memoria di tablespace per la stessa tablespace.

## Probabili cause di aumento delle attese
<a name="ams-waits.innodb-fil-system-mutex.causes"></a>

Quando l’evento `synch/mutex/innodb/fil_system_mutex` appare più che normale, possibilmente indicando un problema di prestazioni, generalmente accade quando sono presenti tutte le seguenti condizioni:
+ Un aumento simultaneo delle operazioni relative al linguaggio di manipolazione dei dati (DM) che che aggiornano o eliminano i dati nella stessa tabella.
+ La tablespace per questa tabella è molto ampia e ha molte pagine di dati.
+ Il fattore di riempimento per queste pagine di dati è basso.

## Azioni
<a name="ams-waits.innodb-fil-system-mutex.actions"></a>

Consigliamo azioni diverse a seconda delle cause dell’evento di attesa.

**Topics**
+ [Identificare le sessioni e le query che causano gli eventi](#ams-waits.innodb-fil-system-mutex.actions.identify)
+ [Riorganizza tabelle di grandi dimensioni durante le ore non di picco](#ams-waits.innodb-fil-system-mutex.actions.reorganize)

### Identificare le sessioni e le query che causano gli eventi
<a name="ams-waits.innodb-fil-system-mutex.actions.identify"></a>

In genere, i database con carico da moderato a significativo hanno eventi di attesa. Gli eventi di attesa possono essere accettabili se le prestazioni sono ottimali. Se le prestazioni non sono ottimali, esaminare dove il database impiega più tempo. Considerare gli eventi di attesa che contribuiscono al carico più elevato per scoprire se è possibile ottimizzare il database e l'applicazione per ridurre tali eventi.

**Per trovare query di SQL responsabili del carico elevato**

1. Accedi a Console di gestione AWS e apri la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).

1. Nel pannello di navigazione scegli **Approfondimenti sulle prestazioni**.

1. Scegli un'istanza database. Viene visualizzato il pannello di controllo di Performance Insights per l'istanza database.

1. Nel grafico **Carico del database**, scegli **Dividi per attesa**.

1. Nella parte inferiore della pagina scegli **Prime Instruzioni SQL**.

   Il grafico elenca le query di SQL responsabili del carico. Quelli in cima all'elenco sono le più responsabili. Per risolvere un collo di bottiglia, occorre concentrarsi su queste istruzioni.

Per una panoramica utile dell’identificazione e della risoluzione dei problemi con Performance Insights, consulta il post del blog[Analizza i carichi di lavoro di Amazon Aurora MySQL con Performance Insights](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/).

Un altro modo per scoprire quali query causano un numero elevato di attese `synch/mutex/innodb/fil_system_mutex` è di controllare `performance_schema`, come nel seguente esempio.

```
mysql> select * from performance_schema.events_waits_current where EVENT_NAME='wait/synch/mutex/innodb/fil_system_mutex'\G
*************************** 1. row ***************************
            THREAD_ID: 19
             EVENT_ID: 195057
         END_EVENT_ID: 195057
           EVENT_NAME: wait/synch/mutex/innodb/fil_system_mutex
               SOURCE: fil0fil.cc:6700
          TIMER_START: 1010146190118400
            TIMER_END: 1010146196524000
           TIMER_WAIT: 6405600
                SPINS: NULL
        OBJECT_SCHEMA: NULL
          OBJECT_NAME: NULL
           INDEX_NAME: NULL
          OBJECT_TYPE: NULL
OBJECT_INSTANCE_BEGIN: 47285552262176
     NESTING_EVENT_ID: NULL
   NESTING_EVENT_TYPE: NULL
            OPERATION: lock
      NUMBER_OF_BYTES: NULL
                FLAGS: NULL
*************************** 2. row ***************************
            THREAD_ID: 23
             EVENT_ID: 5480
         END_EVENT_ID: 5480
           EVENT_NAME: wait/synch/mutex/innodb/fil_system_mutex
               SOURCE: fil0fil.cc:5906
          TIMER_START: 995269979908800
            TIMER_END: 995269980159200
           TIMER_WAIT: 250400
                SPINS: NULL
        OBJECT_SCHEMA: NULL
          OBJECT_NAME: NULL
           INDEX_NAME: NULL
          OBJECT_TYPE: NULL
OBJECT_INSTANCE_BEGIN: 47285552262176
     NESTING_EVENT_ID: NULL
   NESTING_EVENT_TYPE: NULL
            OPERATION: lock
      NUMBER_OF_BYTES: NULL
                FLAGS: NULL
*************************** 3. row ***************************
            THREAD_ID: 55
             EVENT_ID: 23233794
         END_EVENT_ID: NULL
           EVENT_NAME: wait/synch/mutex/innodb/fil_system_mutex
               SOURCE: fil0fil.cc:449
          TIMER_START: 1010492125341600
            TIMER_END: 1010494304900000
           TIMER_WAIT: 2179558400
                SPINS: NULL
        OBJECT_SCHEMA: NULL
          OBJECT_NAME: NULL
           INDEX_NAME: NULL
          OBJECT_TYPE: NULL
OBJECT_INSTANCE_BEGIN: 47285552262176
     NESTING_EVENT_ID: 23233786
   NESTING_EVENT_TYPE: WAIT
            OPERATION: lock
      NUMBER_OF_BYTES: NULL
                FLAGS: NULL
```

### Riorganizza tabelle di grandi dimensioni durante le ore non di picco
<a name="ams-waits.innodb-fil-system-mutex.actions.reorganize"></a>

Riorganizza tabelle di grandi dimensioni che identifichi come fonte di un numero elevato di eventi di attesa `synch/mutex/innodb/fil_system_mutex` durante una finestra temporale di manutenzione al di fuori dell'orario di produzione. In questo modo si assicura che la pulizia della mappa delle tablespace interne non si verifichi quando l'accesso rapido alla tabella è fondamentale. Per informazioni sulla riorganizzazione delle tabelle, consulta [Istruzione OPTIMIZE TABLE](https://dev.mysql.com/doc/refman/5.7/en/optimize-table.html) nel *Riferimento di MySQL*.