Comprensione dell'output iotop (DTT) in Solaris

Durante l'esecuzione di iotop di DTT su un server pesante di scrittura Solaris 10, che gestisce più zone con i demoni MySQL installati, ottengo la seguente output:

   DISPOSITIVO PID PPID CMD UID MAJ MIN D BYTES
    70 26636 1 mysqld sd1 10 64 R 360448
    70 25940 1 mysqld sd1 10 64 R 530432
     0 5 0 zpool-rpool sd1 10 64 W 17250816

Quello che mi disturba qui è il fatto che la zpool-rpool occupa la maggior parte zpool-rpool . Cosa posso fare per vedere quale dei processi MySQL o altri processi veramente occupa l'IO – una ripartizione più elaborata? Se zpool-rpool rappresenta "scrive a ZFS", allora iotop non mi aiuta davvero qui … 🙂

Grazie!

  • Dispositivi ZFS e cache
  • La velocità dello snapshot di ZFS dipende dal numero di file?
  • Ottenere ZFS per statistiche statistiche IO (o statistiche NFS per esportzione IO)
  • Solaris 10 ZFS ARC Maxed Out e CPU sovraccarica
  • scsi e ata per lo stesso disco rigido sotto / dev / disk / by-id
  • Regola di ZFS 80%
  • Manca l'OpenIndiana ZFS con la properties; shareiscsi
  • Gli zfs inviano scrub i dati inviati?
  • 2 Solutions collect form web for “Comprensione dell'output iotop (DTT) in Solaris”

    Potresti trovare la recente serie di blog di Brendan Gregg sulla latenza dei filesystem utili. Mostra un paio di script per indagare l'utilizzo del filesystem con il provider syscall (che dovrebbe essere più affidabile per identificare i processi responsabili del provider io utilizzato da iotop).

    Ad esempio, lo script syscall-read-zfs.d mostrato nella Parte 4 potrebbe essere facilmente modificato per sondare scrive e aggregare su pid anziché execname.

    L'output di questo script può anche essere più utile di iotop perché mostra il numero di IO e la distribuzione della latenza IO per process. Per un database, la latenza delle letture e delle scritture sincrone sono misure dirette del dolore delle performance – è molto più semplice interpretare i byte al secondo.

    Se hai tempo, consiglio vivamente di guardare la sua presentazione a BayLISA per una dimostrazione pratica di come va a studiare i problemi di performance di query MySQL.

    Se si desidera misurare le applicazioni che leggono / scriveranno di più, si desidera misurare a livello di syscall. A livello di periferica sono solo i thread del kernel che fanno il loro lavoro.

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.