Problème d'upload sur serveur web debian

Problème d'upload sur serveur web debian - réseaux et sécurité - Linux et OS Alternatifs

Marsh Posté le 08-06-2017 à 09:36:38    

Bon, je ne savais pas trop où foutre ce sujet, partie réseau/partie linux, donc on va tenter ici !

 

Bonjour !  :fou:

 

Description de la machine

 

VM linux sur un esx (OVH)

 

Distributor ID: Debian
Description:    Debian GNU/Linux 7.0 (wheezy)
Release:        7.0
Codename:       wheezy

 

uname -r
3.2.0-4-amd64

 

Ce serveur a 4 interfaces
- 2 interfaces publiques ( un certain nombre de domaines pointent sur la première, et d'autres sur la seconde, c'est un choix )
- 2 interfaces privées ( une sur un lan où la VM accèdent à d'autres VM, dont SGBD etc, et une sur un vlan sur lequel on a un pfsense qui monte un tunnel VPN jusqu'à chez nous, du coup le serveur est aussi "en local" pour nous)

 

Version de PHP:
PHP Version 5.4.45-0+deb7u2
System Linux nom_de_mon_serveur 3.2.0-4-amd64 #1 SMP Debian 3.2.41-2+deb7u2 x86_64

 

Description de mon putain de problème :

 

On a un de nos sites (pointant sur une des deux IP publiques) sur lequel l'upload de fichiers (via des pages html/php) est devenu foireux un jour, et pas foireux à cause de fichiers trop gros, l'upload est devenu MEGA LENT dès que le fichier dépasse approximativement les 70 ko.

 

Là, suite à un redémarrage du serveur (suite plantage du stockage OVH), ce problème s'est propagé à l'autre interface.

 

Et le pire, c'est que le script qui reçoit le fichier (qui est la même page qui sert à afficher le mini formulaire de test avec un pauvre champ input type file ) ne donne quasi aucun temps d'exécution !
En gros, la page php mets 0.00005698 secondes entre la première ligne de code et la dernière, alors qu'en réalité elle a mise plusieurs minutes à s'afficher.
Sachant que mon script PHP ne fait rien d'autres qu'un var_dump de _FILES.

 

J'ai essayé d'un autre réseau que notre réseau de boite, le résultat est le même, donc ce n'est pas notre parefeu sur site qui merde.

 

Ce qui semble long, c'est donc quand on valide le formulaire et que la page envoie les données (dont notre fichier) à une autre page (donc elle même) et la réception par cette page, pas le traitement ensuite.

 

Rien dans les logs..

 

Exemple, uploader un pauvre fichier a mis plusieurs minutes à s'effectuer, alors que le script n'a duré que quelques secondes en réalité..

 
Code :
  1. array(1) { ["abc"]=> array(5) { ["name"]=> string(14) "fichier.txt" ["type"]=> string(10) "text/plain" ["tmp_name"]=> string(14) "/tmp/phpZBR7wP" ["error"]=> int(0) ["size"]=> int(93536) } }
  2. Exécution du script : 0.00003695 secondes.
 

Mes

 
Code :
  1. upload_max_filesize
  2. post_max_size
  3. max_execution_time
  4. max_input_time
 

ne posent pas de problème, l'upload se fait, que le fichier fasse 3ko, 100ko, ou 2Mo, c'est juste qu'au delà de 70ko, même sur une ligne fibre 10Gb, la page mettra plusieurs minutes à gérer l'envoi/réception.

 

Toutes les pages de nos sites s'affichent dans des délais corrects, le top ne me parait pas déconnant :

 
Code :
  1. top - 09:32:39 up 1 day, 23:47,  2 users,  load average: 3,75, 3,22, 2,55
  2. Tasks: 224 total,   4 running, 219 sleeping,   0 stopped,   1 zombie
  3. %Cpu(s): 43,0 us,  2,8 sy,  0,0 ni, 53,0 id,  0,0 wa,  0,0 hi,  1,3 si,  0,0 st
  4. KiB Mem:   8197076 total,  4453008 used,  3744068 free,   260980 buffers
  5. KiB Swap:        0 total,        0 used,        0 free,  2465476 cached
 

Le CPU varie entre 20 et 70, fait sa petite vie quoi.

 

Merci de me dire si ce n'est pas la bonne section, je copie-collerai.

 

Je sèche sur la résolution du problème, je ne suis pas expert serveur (dans ma boite, on fait tout, de la mise en place des serveurs, dev d'applications, accrochage des tableaux au mur et j'en passe, et sur certains aspects, je ne suis pas aussi compétent qu'une personne dédiée, typiquement sur ce genre de problème).

 

Thanks

 

[edit: console chrome pour un upload de moins de 300ko .. ]
https://img4.hostingpics.net/pics/404586uploadslow.png


Message édité par hinomura le 08-06-2017 à 10:20:42
Reply

Marsh Posté le 08-06-2017 à 09:36:38   

Reply

Marsh Posté le 08-06-2017 à 10:32:37    

Etape 1:
- circonscrire le problème : est-ce que tu observes le même comportement avec des protocoles différents (type scp/ftp) ?
=> tu sauras s'il s'agit plus d'un problème réseau (TCP ou en dessous) qu'un problème applicatif (ton infra web)


Message édité par o'gure le 08-06-2017 à 10:33:21

---------------
Relax. Take a deep breath !
Reply

Marsh Posté le 08-06-2017 à 10:46:42    

J'ai parfois des résultats approximatifs en FTP ...
 

Code :
  1. Réponse : 150 Accepted data connection
  2. Erreur : Could not write to transfer socket: ECONNRESET - Connexion réinitialisée par un pair
  3. Réponse : 226-Error during read from data connection
  4. Réponse : 226-Transfer aborted
  5. Réponse : 226 19.552 seconds (measured here), 3.31 Kbytes per second
  6. Erreur : Échec du transfert du fichier après avoir transféré 524 288 octets en 19 secondes


 
Et parfois ça roule, mais petit fichier là (2ko):
 

Code :
  1. Démarrage de l'envoi de x:\DEPOTS\........\entete.php
  2. Statut : Transfert de fichier réussi, 1 202 octets transférés en 1 seconde
  3. Statut : Récupération du contenu du dossier "/rep_distant"...
  4. Statut : Contenu du dossier "/rep_distant" affiché avec succès


 
Sachant qu'on envoie aussi des données via des push git qui passent (mais c'est des faibles volumes de données )
 
En download, moins de soucis :

Code :
  1. Statut : Transfert de fichier réussi, 25 861 431 octets transférés en 9 secondes


Message édité par hinomura le 08-06-2017 à 10:56:13
Reply

Marsh Posté le 08-06-2017 à 11:05:17    

En info compl, qui vient de temporairement résoudre mon soucis, ma dernière interface est en dhcp (celle sur le vlan qui va taper dans le pfsense).
Du coup, dhcp = modif auto du resolv.conf ...

 

Donc je l'ai mis en static, j'ai remis vite fait mon resolv.conf propre, et ça va beaucoup mieux sur mes premiers tests ...

 

Donc en avance, merci o'gure (c'est con, mais j'en étais resté à un problème d'apache sans voir plus loin que le bout de mon nez niveau couche réseau)

 

[edit]
Ca a donc temporairement résolu ce problème qui était venu se foutre sur les sites "hébergés" sur mon interface eth0 avec l'ip publique "A".

 

Par contre, sur les sites hébergés sur l'interface eth1 (avec l'ip publique "B" touSSa), le problème reste.

 

Je continue de creuser coté réseau donc.


Message édité par hinomura le 08-06-2017 à 14:03:32
Reply

Marsh Posté le 14-06-2017 à 14:58:24    

Bon, le problème revient et m'oblige à redémarrer l'interface réseau pour un retour à la normale.

Reply

Marsh Posté le 17-06-2017 à 14:15:09    

c'est quoi ta conf tcp/ip de ta vm ? et la table de routage ?
C'est quoi l'intérêt d'avoir 2 interfaces ? C'est des vrais réseaux séparés ? Parce que ta gateway elle est unique.
Tu as pas de traces tcpdump ou autre voir si bcp de paquets se perdent etc. ?

Message cité 1 fois
Reply

Marsh Posté le 08-08-2017 à 09:04:27    

Je@nb a écrit :

c'est quoi ta conf tcp/ip de ta vm ? et la table de routage ?
C'est quoi l'intérêt d'avoir 2 interfaces ? C'est des vrais réseaux séparés ? Parce que ta gateway elle est unique.
Tu as pas de traces tcpdump ou autre voir si bcp de paquets se perdent etc. ?


Salut, désolé, pas vu ce message.
 
En fait historiquement on avait deux IP publiques parce que 2 sites en HTTPS distincts et qu'on ne voulait pas un certificat global (beaucoup plus cher je crois).
 
Et comme créer une carte réseau sur une VM ça ne coute rien ;)
 
J'avance un peu sur ce problème, qui semble être donc un problème réseau plus qu'autre chose:
 
J'ai remarqué que les deux interfaces fonctionnent (les sites sur chaque interface sont OK), mais j'ai quand même un problème sur eth2 (l'interface sur lequel le problème d'upload se produit).
 
En effet, un ifup ou ifdown sur cette interface crash un message d'erreur, et le fichier ifstate n'intègre pas cette interface (je peux bien l'ajouter à la main, il dégage au prochain networking restart )
 
Un état de mon ifstate:
 

Code :
  1. cat /run/network/ifstate
  2. lo=lo
  3. eth0=eth0
  4. eth1=eth1


 
eth2 n'est pas présent
 
ifdown / ifup eth2
 

Code :
  1. root@XXX:~#ifdown eth2
  2. ifdown: interface eth2 not configured
  3. root@XXX:~# ifup eth2
  4. RTNETLINK answers: File exists
  5. Failed to bring up eth2


 
mes routes, qui peuvent aussi poser souci puisqu'une seule route par défaut par une seule carte, ou pas ?
 

Code :
  1. root@XXX:~# route -n
  2. Table de routage IP du noyau
  3. Destination     Passerelle      Genmask         Indic Metric Ref    Use Iface
  4. 0.0.0.0         X.X.X.222   0.0.0.0         UG    0      0        0 eth0
  5. X.X.X.208   0.0.0.0         255.255.255.240 U     0      0        0 eth2
  6. X.X.X.208   0.0.0.0         255.255.255.240 U     0      0        0 eth0
  7. Y.Y.100.0   0.0.0.0         255.255.255.0   U     0      0        0 eth1


 
Sachant que j'avais du ajouter/supprimer des cartes réseaux un moment donné pour checker ce problème, j'ai l'impression qu'il y a un truc résiduel.
 
Les cartes marchent, eth0 et eth1 sans soucis (pas d'upload web sur eth1), eth2 marche sauf pour cet upload.
 
Mes cartes:
 

Code :
  1. root@XXX:~# lspci | egrep -i --color 'network|ethernet'
  2. 02:00.0 Ethernet controller: Intel Corporation 82545EM Gigabit Ethernet Controller (Copper) (rev 01)
  3. 02:01.0 Ethernet controller: Intel Corporation 82545EM Gigabit Ethernet Controller (Copper) (rev 01)
  4. 02:02.0 Ethernet controller: Intel Corporation 82545EM Gigabit Ethernet Controller (Copper) (rev 01)


 
 

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed