[Linux] Serveur qui gèle si on y copie un fichier trop grand ?
Jean-Marc Libs
jeanmarc.libs@::1
Dim 26 Aou 23:01:06 CEST 2018
Comme dit à Éric, c'est en prod alors c'est fini de le planter
volontairement !
Je note pour le cas où j'ai l'occasion d'y repasser du temps.
Le noyau:
root@::1:~# uname -a
Linux firstheberg01 4.15.0-32-generic #35-Ubuntu SMP Fri Aug 10 17:58:07
UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
( "Ubuntu 18.04.1 LTS" toute neuve et bien à jour)
Carte réseau :
root@::1:~# lspci
00:00.0 Host bridge: Intel Corporation Atom Processor D4xx/D5xx/N4xx/N5xx
DMI Bridge (rev 02)
00:02.0 VGA compatible controller: Intel Corporation Atom Processor
D4xx/D5xx/N4xx/N5xx Integrated Graphics Controller (rev 02)
00:1b.0 Audio device: Intel Corporation NM10/ICH7 Family High Definition
Audio Controller (rev 02)
00:1c.0 PCI bridge: Intel Corporation NM10/ICH7 Family PCI Express Port 1
(rev 02)
00:1d.0 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI
Controller #1 (rev 02)
00:1d.1 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI
Controller #2 (rev 02)
00:1d.2 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI
Controller #3 (rev 02)
00:1d.3 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI
Controller #4 (rev 02)
00:1d.7 USB controller: Intel Corporation NM10/ICH7 Family USB2 EHCI
Controller (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2)
00:1f.0 ISA bridge: Intel Corporation NM10 Family LPC Controller (rev 02)
00:1f.2 SATA controller: Intel Corporation NM10/ICH7 Family SATA Controller
[AHCI mode] (rev 02)
00:1f.3 SMBus: Intel Corporation NM10/ICH7 Family SMBus Controller (rev 02)
01:00.0 Ethernet controller: *Qualcomm Atheros AR8151 v2.0 Gigabit Ethernet
(rev c0)*
ou
root@::1:~# lshw -class network
*-network
description: Ethernet interface
product: AR8151 v2.0 Gigabit Ethernet
vendor: Qualcomm Atheros
physical id: 0
bus info: pci@::1:01:00.0
logical name: eth0
version: c0
serial: bc:5f:f4:0c:8c:40
size: 1Gbit/s
capacity: 1Gbit/s
width: 64 bits
clock: 33MHz
capabilities: pm msi pciexpress vpd bus_master cap_list ethernet
physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
configuration: autonegotiation=on broadcast=yes driver=atl1c
driverversion=1.0.1.1-NAPI duplex=full ip=91.236.239.44 latency=0 link=yes
multicast=yes port=twisted pair speed=1Gbit/s
resources: irq:27 memory:febc0000-febfffff ioport:ec00(size=128)
T'as une commande pour la version du driver ? Ça me vient pas, là :-(
Merci pour les pistes. Si ça se passe mal, ce sera précieux !
J-M
On Sun, Aug 26, 2018 at 8:23 PM Cyril Chaboisseau <cyril.chaboisseau@::1>
wrote:
> ...et un autre test pour avoir confirmation : désactiver TCP Selective
> Acknowledgment/SACK avec le MTU à 1500
>
> ça ne devrait pas geler la machine
>
> quel carte réseau as-tu ?
> (et quelle version du driver et du noyau ?)
>
>
> * Éric Bischoff <ebischoff@::1> [2018-08-25 14:46 +0200]:
>
> > Le vendredi 24 août 2018, 18:09:57 CEST Jean-Marc Libs a écrit :
> > > Oui.
> > > Honnêtement, que le transfert gèle, je peux comprendre. Que ça
> entraîne un
> > > plantage du serveur entier, j'ai du mal à comprendre le mécanisme.
> Problème
> > > hardware ? Driver réseau ?
> >
> > Je te soumets une hyporthèse farfelue. Si tu as le temps :
> >
> > Remets le MTU à 1500 et enlève avec ethtool toute l'assistance
> matérielle au
> > niveau de la carte.
> >
> > http://docs.gz.ro/node/282
> >
> > Si le problème disparaît aussi comme ça, c'est que c'est le software
> embarqué
> > dans la carte qui réagit mal à un mauvais MTU.
> >
> > Mon raisonnement, qui est peut-être idiot, c'est qu'une interface serait
> > éventuellement capable de geler le système entier...
> >
> >
>
> --
> Cyril Chaboisseau
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <https://strasbourg.linuxfr.org/pipermail/linux/attachments/20180826/923e53d6/attachment-0001.html>
Plus d'informations sur la liste de diffusion linux