Problème d'upload sur serveur web debian

Recherche :

Mot : Pseudo : Filtrer
Bas de page
Auteur	Sujet : Problème d'upload sur serveur web debian

hinomura

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 :

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) } }
Exécution du script : 0.00003695 secondes.

Mes

Code :

upload_max_filesize
post_max_size
max_execution_time
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 :

top - 09:32:39 up 1 day, 23:47, 2 users, load average: 3,75, 3,22, 2,55
Tasks: 224 total, 4 running, 219 sleeping, 0 stopped, 1 zombie
%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
KiB Mem: 8197076 total, 4453008 used, 3744068 free, 260980 buffers
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 .. ]

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

Publicité

o'gure

Modérateur
Multi grognon de B_L

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 !

hinomura

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

Code :

Réponse : 150 Accepted data connection
Erreur : Could not write to transfer socket: ECONNRESET - Connexion réinitialisée par un pair
Réponse : 226-Error during read from data connection
Réponse : 226-Transfer aborted
Réponse : 226 19.552 seconds (measured here), 3.31 Kbytes per second
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 :

Démarrage de l'envoi de x:\DEPOTS\........\entete.php
Statut : Transfert de fichier réussi, 1 202 octets transférés en 1 seconde
Statut : Récupération du contenu du dossier "/rep_distant"...
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 :

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

hinomura

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

hinomura

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

Je@nb

Kindly give dime

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

hinomura

Je@nb a écrit :

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 :

cat /run/network/ifstate
lo=lo
eth0=eth0
eth1=eth1

eth2 n'est pas présent

ifdown / ifup eth2

Code :

root@XXX:~#ifdown eth2
ifdown: interface eth2 not configured
root@XXX:~# ifup eth2
RTNETLINK answers: File exists
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 :

root@XXX:~# route -n
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
0.0.0.0 X.X.X.222 0.0.0.0 UG 0 0 0 eth0
X.X.X.208 0.0.0.0 255.255.255.240 U 0 0 0 eth2
X.X.X.208 0.0.0.0 255.255.255.240 U 0 0 0 eth0
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 :

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

FORUM HardWare.fr

Linux et OS Alternatifs

réseaux et sécurité

Problème d'upload sur serveur web debian

Sujets relatifs
debian server vnc marche pas	Problème installation Ipcop
[Debian][Xorg][Fluxbox] Fenêtres applications invisibles [Résolu]	Programmation tâche quotidienne sous debian 8
Zimbra serveur	Probléme Base de donnée sur un Debian 8.7 x64
Problème de connexion sur un NAS avec OpenMediaVault	[Résolu] Kingston DT Vault Privacy non accessible depuis debian
Problème pour un client nomade de openvpn d'acceder aux postes du LAN
Plus de sujets relatifs à : Problème d'upload sur serveur web debian

Page générée en 0.070 secondes