Question Quel type de matériel de serveur Web utilisez-vous pour gérer plus de 100 Mbps de fichiers statiques?


J'utilise actuellement Amazon S3 pour la plupart de mes besoins en fichiers statiques, mais ma facture mensuelle devient très chère. J'ai fait quelques calculs approximatifs à l'aide des journaux et, aux heures de pointe, mon compartiment le plus cher sur Amazon traite de 100 180 Mbps de trafic. Surtout des images de moins de 50K.

S3 est extrêmement utile en matière de stockage et de redondance, mais je n'ai pas vraiment besoin de payer pour la bande passante et les requêtes GET si je peux m'aider. Comme je dispose de beaucoup de bande passante peu coûteuse dans mon propre centre de données, j'ai donc configuré un serveur nginx en tant que proxy de mise en cache, puis amorcé le cache avec la majeure partie de mes fichiers (environ 240 Go) afin que mon disque n'écrive pas comme un fou sur un ordinateur. cache vide.

J'ai essayé de couper et mon mon serveur étouffé.

Le problème semble être mes disques - cette machine a 4 disques SATA de 1 To (Barracuda XT) configurés en RAID 10. C'est la seule chose qui me reste avec suffisamment d'espace de stockage pour être utilisé à cette fin. Je suis presque sûr que nginx a été configuré correctement, car je l'utilisais déjà en tant que proxy de mise en cache pour un autre compartiment Amazon plus petit. En supposant qu'il s'agisse d'une quantité de trafic raisonnable pour une seule machine, un disque SSD vaudrait peut-être la peine d'essayer.

Si vous gérez de grandes quantités de fichiers statiques, quel matériel utilisez-vous?

Information additionnelle 

Système de fichiers: ext4, noatime monté, barrière = 0, données = écriture, nobh (j'ai la batterie de secours sur le contrôleur) Nginx: worker_connections = 4096, worker_rlimit_nofile 16384, worker_processes 8, open_file_cache max = 100000 inactive = 60m


5
2017-10-03 20:59


origine


Etes-vous sûr que le goulot d'étranglement est votre configuration de disque ou rencontrez-vous des problèmes de pagination dus au débordement de la mémoire système? - Cypher
Non, pas de permutation .. et environ 40 Go de mémoire libre. - Casey
Donc ... ma question n'était pas "mes disques sont-ils le problème"? Ils sont le problème (ou ... ils sont tellement un problème qu'ils masquent tout autre problème). Je me demandais simplement ce que les autres personnes utilisent pour gérer ce type de trafic. - Casey
Avez-vous déterminé la taille d'une partie de vos fichiers activement utilisés? S'agit-il des mêmes 5% de fichiers serveurs 95% du temps ou est-ce que la distribution est plus uniforme? Réchauffer votre cache de blocs peut faire toute la différence en supposant que le gros de vos demandes concerne un ensemble de fichiers légèrement inférieur à la quantité de RAM dont vous disposez. - EvilRyry
Une pensée rapide: avez-vous mis Noatime? - BMDan


Réponses:


Je ne pense pas que votre disque soit le problème. Tout d'abord, ncache de nginx utilise un magasin de disques pour le cache. La vitesse du disque sera donc une cause potentielle de problèmes en fonction de la chaleur ou de la froideur de votre jeu de données. Cependant, je ne vois aucune raison pour que vous ne puissiez pas fournir 100 Mo / s avec le matériel que vous avez mentionné, en particulier si vous ' re utilisant nginx.

La première chose à laquelle je pense, c’est que votre nombre de processus de travail était faible, que vos connexions de travailleur étaient probablement beaucoup trop basses et que votre ensemble open_file_cache n’était pas assez élevé. Cependant, aucun de ces paramètres ne provoquerait un temps d'attente IO élevé ni un pic comme celui-là. Vous dites que vous diffusez <50 000 images et il semble qu'un quart de votre série pourrait facilement être mis en mémoire tampon par le système d'exploitation. Nginx n'est sûrement pas configuré de manière optimale.

Varnish traite le problème de manière légèrement différente en utilisant de la RAM plutôt que du disque pour son cache.

Cela dépend en grande partie de votre jeu de données, mais, en fonction des données que vous avez fournies, je ne vois aucune raison pour que les entrées / sorties sur disque aient une telle ampleur. Avez-vous vérifié dmesg et les journaux pour voir si l’un de vos lecteurs avait rencontré des erreurs d’entrée-sortie à l’époque? La seule autre chose que je puisse penser qui aurait pu causer ce pic était le dépassement du cache de fichiers de nginx, ce qui l’aurait obligé à passer en mode FIFO ouvrant de nouveaux fichiers.

Assurez-vous que votre système de fichiers est monté avec noatime, ce qui devrait réduire considérablement votre charge de travail en écriture.

Par exemple, une machine qui gère régulièrement 800 Mo / s:

# uptime
 11:32:27 up 11 days, 16:31,  1 user,  load average: 0.43, 0.85, 0.82

# free
             total       used       free     shared    buffers     cached
Mem:       8180796    7127000    1053796          0       1152    2397336
-/+ buffers/cache:    4728512    3452284
Swap:      8297568     237940    8059628

Quadcore Xeon:
    Intel(R) Xeon(R) CPU           X3430  @ 2.40GHz

$ ./bw.pl xxx.xxx 2010-09-01 2010-09-30
bw: 174042.60gb

average 543mb/sec, peaks at 810mb/sec

=== START OF INFORMATION SECTION === Model Family:     Seagate Barracuda
7200.12 family Device Model:     ST3500418AS Serial Number:    6VM89L1N
Firmware Version: CC38 User Capacity: 
500,107,862,016 bytes

Linux 2.6.36-rc5 (xxxxxx)   10/04/2010  _x86_64_    (4 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           4.33    0.00    2.40    5.94    0.00   87.33

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda             109.61     19020.67       337.28 19047438731  337754190

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           8.09    0.00    3.40   10.26    0.00   78.25

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda             138.52     21199.60       490.02     106210       2455

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           3.74    0.00    3.25    9.01    0.00   84.00

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda             125.00     21691.20       139.20     108456        696

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           4.75    0.00    3.12   14.02    0.00   78.11

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda             154.69     19532.14       261.28      97856       1309

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           6.81    0.00    3.36    9.48    0.00   80.36

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda             112.80     17635.20       309.00      88176       1545

MRTG:

http://imgur.com/KYGp6.png

Jeu de données:

# du -sh ads
211.0G  ads

# ls|wc -l
679075

2
2017-10-04 15:34



Pourquoi voudriez-vous que ncache mette en cache des fichiers statiques sur des disques qui se trouvent déjà sur le disque? Le noyau devrait effectuer lui-même un bon travail de mise en cache. - EvilRyry
Sa question indiquait qu'il avait Nginx dans son centre de données en train de mettre en cache un compartiment S3. Mes données montrent simplement que Nginx fonctionnant sur du matériel correct est capable de gérer 8 fois ses besoins, ce qui était la deuxième partie de sa question. Quelle partie avez-vous trouvé déroutante pour que je puisse modifier ma réponse? - karmawhore
Génial - merci pour l'info du monde réel. J'ai ajouté quelques informations supplémentaires sur nginx et la configuration du système de fichiers à ma question. - Casey
Traiter environ 1/3 des requêtes maintenant à titre expérimental, pas de problèmes. Mes lectures IOPS sont à 120-140. - Casey
lancez iostat-x 5 5 frappez-vous à 100% (ou presque) sur l’un des disques? worker_rlimit_nofile / worker_connections semble faible pour la quantité de trafic que vous poussez, mais je ne vois rien qui puisse causer le problème que vous aviez. Je ne me souviens pas comment nginx gère le nettoyage des LRU - est-il possible que tout votre contenu ait expiré au moment où votre E / S est montée en flèche? à quoi était destiné votre vie? - karmawhore


Votre. Disques. Sucer. Point.

  • Essayez d’obtenir des disques de plus en plus rapides. SAS vient bien ici, comme Velociraptors doe.

  • Cela dit, le mieux serait d'obtenir… un SSD.

Vos disques font probablement environ 200 IOPS chacun. Avec SAS, vous pouvez en obtenir jusqu’à 450, avec Velocidaptors, environ 300. Un SSD haut de gamme peut vous rapporter ... 50 000 (sans blague - je veux dire vraiment 5 0 0 0 0 0 0) IOPS.

Faites le calcul;) Un SSD unique, pas de RAID, serait environ 62 fois plus rapide que votre Raid 10;)


2
2017-10-04 02:00





Nous desservons environ 600 Mbits / s à partir d'un serveur avec des disques SSD sur le serveur principal et nginx + vernn sur le front. Le processeur actuel est un peu Intel Atom; nous en avons quatre derrière un LB à 600 Mbits / s chacun (avec DSR). Peut-être pas approprié pour chaque situation, mais cela a été parfait pour notre cas d'utilisation.


1
2017-10-04 17:27





La machine que vous utilisez a-t-elle suffisamment de mémoire RAM pour que l'ensemble de fichiers de travail soit mis en cache dans la RAM?

Aussi - avez-vous regardé quelque chose comme Varnish? Nginx est idéal pour gérer des tonnes de connexions - mais ce n'est pas le summum en termes de cache et de performances système.


0
2017-10-03 21:13





Ajoutez beaucoup plus de disques. Vous pouvez échanger la vitesse d’un disque avec le nombre de disques (jusqu’à un certain point): vous pouvez peut-être obtenir les mêmes performances avec des disques X coûteux SAS 15kRPM ou avec (devinons, sans valeurs significatives) X * 2 disques SATA 7k2RPM économiques. Vous devez faire vos calculs et voir ce qui est le mieux pour vous - et cela dépend aussi de combien vous payez l'espace de rack et la puissance de votre centre de données.

SSD vous fournira toutes les IOPS dont vous aurez besoin, mais elles ne sont pas bon marché pour le stockage en masse (c'est pourquoi leur principal cas d'utilisation est une base de données comme des charges de travail).


0
2017-10-04 08:51