Comment configurer nginx pour servir le contenu statique de la RAM?

11

Je souhaite configurer Nginx comme mon serveur Web. Je souhaite que les fichiers image soient mis en cache dans la mémoire (RAM) plutôt que sur le disque. Je sers une petite page et je veux que quelques images soient toujours servies à partir de la RAM. Je ne souhaite pas utiliser Varnish (ou tout autre outil de ce type) pour cela, car je crois que Nginx a la capacité de mettre en cache le contenu dans la RAM. Je ne sais pas comment je peux configurer Nginx pour cela? J'ai essayé quelques combinaisons mais elles n'ont pas fonctionné. Nginx utilise tout le temps le disque pour obtenir les images.

Par exemple, lorsque j'ai essayé le benchmark Apache pour tester avec la commande suivante:

ab -c 500 -n 1000 http://localhost/banner.jpg

J'obtiens l'erreur suivante:

socket: Too many open files (24)

Je suppose que cela signifie que Nginx essaie d'ouvrir trop de fichiers simultanément à partir du disque et que le système d'exploitation n'autorise pas cette opération. Quelqu'un peut-il me suggérer une configuration correcte?

nginx cache memcache

— Vijayendra
source

Vous vous trompez presque certainement. De plus, d'où tirez-vous l'erreur?

— womble

@womble Comme je le commente ci-dessous, le problème pourrait être la concurrence. De nombreux threads essaient simultanément avant que le contenu ne soit disponible en mémoire. Pouvez-vous expliquer pourquoi pensez-vous que je me trompe?

— Vijayendra

9

S'il s'agit d'un contenu statique, il sera mis en cache par défaut (sauf s'il n'y a plus de mémoire), pas par nginx, mais par OS - tout ce qui restera côté disque sera stat ().

Si vous voulez une solution de mémoire à 100%, vous pouvez simplement configurer le disque virtuel et servir les données à partir de là.

— c2h5oh
source

Oui, je comprends que le contenu est mis en cache par le système d'exploitation. Mais l'hypothèse est que le fichier est déjà disponible en mémoire. Le problème pourrait être la simultanéité. De nombreux threads essaient simultanément avant que le contenu ne soit disponible dans la mémoire. Qu'est-ce que tu penses?

— Vijayendra

1

Ce n'est un problème que si le nombre de demandes passe de 0 à 500 en un instant - une fois le fichier lu, il y sera stocké jusqu'à ce que la mémoire soit nécessaire (le fichier le moins récemment utilisé est supprimé du cache si la mémoire est pleine et que le nouveau fichier a besoin à mettre en cache). Les chances que cela se produise dans la vie réelle sont minimes. Si vous êtes sûr que c'est un risque réel, utilisez plutôt la solution ramdisk, assurez-vous simplement de restaurer les données sur ramdisk après chaque redémarrage - ramdisk n'est pas un stockage persistant par définition.

— c2h5oh

Ok, je vais essayer ramdisk et voir comment cela fonctionne. Merci pour les commentaires.

— Vijayendra

9

Une fois que le serveur a lu un fichier sur le disque, il sera mis en cache dans ram (et sera remplacé par un fichier différent si vous n'avez plus de ram), le problème est avec votre limite de compte, vous ne pouvez pas ouvrir autant de fichiers ( exécutez 'ulimit -a'),

Si vous souhaitez modifier cette limite - lisez à propos de /etc/security/limits.conf

— Avi Keinan
source

1

Vous avez raison, la limite de fichiers ouverts était un problème car la limite est de 256 sur mon système. Mais j'ai encore besoin de comprendre comment configurer Nginx pour lire les fichiers de la mémoire plutôt que du disque. Je ne souhaite pas modifier ma limite de fichiers ouverts et souhaite plutôt utiliser le cache pour les demandes suivantes.

— Vijayendra

4

"Je ne souhaite pas modifier ma limite de fichiers ouverts" - vous vous trompez. Oh, donc très, très mal.

— womble

3

@womble Je comprends que pour résoudre le problème, la solution la plus simple consiste à modifier la limite. La raison pour laquelle je ne souhaite pas modifier cette limite est de voir ce que je peux faire de mieux avec la configuration sans modifier la limite. Je pense pouvoir améliorer les choses en modifiant certains autres aspects de la mise en cache et de la configuration. Et en passant, pouvez-vous s'il vous plaît vous donner des raisons / suggestions tout en affirmant pourquoi quelqu'un a tort. Même dans votre premier commentaire, vous avez fait cela sans donner de raison. Ceci est un endroit pour donner des suggestions professionnelles, veuillez cesser de le traiter comme votre mur Facebook.

— Vijayendra

7

Je sais donc que c'est vraiment vieux mais, c'est parti.

Nginx ne fait pas de mise en cache de mémoire hors de la boîte, vous voudrez regarder memcache pour cela, je recommanderais le pack openresty pour cela: http://openresty.org/. Ce que vous sortez de la boîte (comme cela a été répondu ci-dessus est le cache de page)
Ce message d'erreur, je suis presque certain, vient de ab et non de nginx, les erreurs nginx pour les limites de fichiers ressemblent à ceci "a échoué (24: trop de fichiers ouverts)". N'oubliez pas que les sockets unix sont également des fichiers, donc pour l'utilisateur que vous exécutez ab as, doit avoir son ulimit ajusté pour que cette session s'exécute ab. Puisque vous avez dit que votre limite était de 256, vous demandez à ab d'utiliser 500 connexions, c'est le maximum de votre limite.

— Ben Whitaker
source

Ben Whitaker avait raison, le problème est venu de ab, qui essaie de créer 500 fichiers de sockets <=> (sous Linux).

— bachden

2

Un fichier mis en cache dans la RAM est toujours un fichier!

Essayez plutôt d'utiliser le module de cache Memcached de Nginx. Mais encore, 1000 connexions simultanées sont énormes, pensez-vous que ce soit votre cas?

— Thomas Decaux
source