Comment utiliser la mémoire partagée dans nginx

L'utilisation du fichier ngx_shmem

ngx_shmem.c/h n'est qu'une encapsulation très simple de l'appel système mmap()/munmap() ou shmget()/shmdt(). Implémentation de la bibliothèque de base de style ngx, qui peut demander et libérer un espace mémoire partagé continu. Il est généralement utilisé pour les données partagées de longueur fixe. La longueur des données est fixe et ne s'étendra ni ne diminuera pendant l'utilisation.

typedef struct {
  u_char   *addr;
  size_t    size;
  ...
} ngx_shm_t;
ngx_int_t ngx_shm_alloc(ngx_shm_t *shm);
void ngx_shm_free(ngx_shm_t *shm);

Le processus d'utilisation de la mémoire partagée dans ngxin est généralement créé par le processus maître, et le processus de travail obtient le pointeur de mémoire par héritage.

Concernant l'utilisation de ngx_shmem, vous pouvez vous référer à quelques extraits dans ngx_event_module_init() Cette partie du code crée plusieurs variables dans la mémoire partagée pour enregistrer le nombre de requêtes dans chaque statut (acceptée/lecture/écriture...) , et dans Plusieurs entrées d'événements clés dans ngx_event_module effectuent des opérations statistiques d'addition et de soustraction sur ces variables. Implémentez des statistiques sur l’état actuel des demandes de tous les processus de travail.

shm.size = size;
ngx_str_set(&shm.name, "nginx_shared_zone");
shm.log = cycle->log;

if (ngx_shm_alloc(&shm) != ngx_ok) {
  return ngx_error;
}

shared = shm.addr;
...
ngx_stat_accepted = (ngx_atomic_t *) (shared + 3 * cl);
ngx_stat_handled = (ngx_atomic_t *) (shared + 4 * cl);
ngx_stat_requests = (ngx_atomic_t *) (shared + 5 * cl);
ngx_stat_active = (ngx_atomic_t *) (shared + 6 * cl);
ngx_stat_reading = (ngx_atomic_t *) (shared + 7 * cl);
ngx_stat_writing = (ngx_atomic_t *) (shared + 8 * cl);
ngx_stat_waiting = (ngx_atomic_t *) (shared + 9 * cl);

Pour plus de détails sur cette fonction, vous pouvez afficher le code associé à la définition de la macro ngx_stat_stub et ngx_http_stub_status_module dans le code.

Utilisation de ngx_slab

ngx_shmem est un package minimaliste qui implémente les fonctions de base de la mémoire partagée. Cependant, la plupart des données de scène partagées dans notre programme n'ont pas de structure de taille fixe, mais plutôt une structure de données de taille variable telle que ngx_array, ngx_list, ngx_queue et ngx_rbtree.

Nous espérons disposer d'un pool de mémoire capable de demander et de libérer dynamiquement de l'espace comme ngx_pool_t. ngx_slab est exactement une telle structure. En principe, elle est similaire à malloc() du système dans la mesure où elle utilise une série d'algorithmes pour demander et libérer des segments de mémoire. C'est juste que l'objet exploité par ngx_slab est une mémoire partagée basée sur ngx_shmem.

Premier coup d'œil à l'interface de ngx_slab

typedef struct {
  ngx_shmtx_t    mutex;
  ...
  void       *data; /* 一般存放从pool中申请获得的根数据地址（pool中第一个申请的数据接口） */
  void       *addr; /* 使用ngx_shmem申请获得的共享内存基地址 */
} ngx_slab_pool_t;

void ngx_slab_init(ngx_slab_pool_t *pool);
void *ngx_slab_alloc(ngx_slab_pool_t *pool, size_t size);
void *ngx_slab_alloc_locked(ngx_slab_pool_t *pool, size_t size);
void *ngx_slab_calloc(ngx_slab_pool_t *pool, size_t size);
void *ngx_slab_calloc_locked(ngx_slab_pool_t *pool, size_t size);
void ngx_slab_free(ngx_slab_pool_t *pool, void *p);
void ngx_slab_free_locked(ngx_slab_pool_t *pool, void *p);

Vous pouvez voir que l'interface n'est pas compliquée. La différence entre alloc et calloc est de savoir s'il faut effacer le segment mémoire obtenu par l'application. L'interface à la fin de _locked indique que le fonctionnement. la piscine a acquis le verrou. Il existe un mutex ngx_shmtx_t dans la structure ngx_slab_pool_t, qui est utilisé pour synchroniser le scénario simultané de plusieurs processus accédant au pool en même temps. Notez que ngx_slab_alloc() va d'abord acquérir le verrou, puis demander de l'espace et enfin libérer le verrou. Et ngx_slab_alloc_locked() s'applique directement à l'espace, pensant que le programme a obtenu le verrou dans une autre logique.

L'utilisation de ngx_shmem dans le développement nginx nécessite généralement de suivre le processus d'initialisation suivant :

• Le module appelle l'interface ngx_shared_memory_add() pendant le processus d'analyse de la configuration pour enregistrer une mémoire partagée. Fournit des fonctions de rappel pour la taille de la mémoire partagée et l’initialisation de la mémoire.

• Le framework utilise ngx_shmem dans ngx_init_cycle() pour demander de la mémoire, initialiser ngx_slab, puis rappeler la fonction d'initialisation enregistrée par le module

• Le module utilise l'interface application/si de ngx_slab

Dans ce processus, ngx_shared_memory_add est impliqué () interface et structure ngx_shm_zone_t correspondante.

struct ngx_shm_zone_s {
  void           *data;
  ngx_shm_t         shm;
  ngx_shm_zone_init_pt   init;
  void           *tag;
  void           *sync;
  ngx_uint_t        noreuse; /* unsigned noreuse:1; */
};
ngx_shm_zone_t *ngx_shared_memory_add(ngx_conf_t *cf, ngx_str_t *name,
  size_t size, void *tag);

L'une des choses qui méritent d'être mentionnées est l'attribut noreuse. Cet attribut contrôle si la mémoire partagée sera réappliquée pendant le processus de rechargement de nginx.

Étant donné que la fonction ngx_init_cycle() est longue, ce processus peut être visualisé en recherchant le commentaire /* create shared memory */ ou l'objet cycle->shared_memory pour afficher le code correspondant.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!