Linux s'essoufle avec le temps ?

Linux s'essoufle avec le temps ? - Divers - Linux et OS Alternatifs

Marsh Posté le 07-04-2005 à 09:31:16    

Salut,
 
j'ai un serveur (de fichiers principalement) depuis pas mal de temps sous Debian Woody.
Depuis qq mois, j'ai des problèmes lorsque je grave de mon pc windows xp des données stockées sur le serveur (samba), les buffers s'excitent et la gravure echoue/dure super longtemps. Je n'avais rien de tout ca avant.
 
les disques durs ne semblent pas malade (smart ok).
 
Est ce normal ?
Que puis je vérifier ?
 
Merci.


---------------
Le droit à la différence s'arrête là où ça commence à m'emmerder sérieusement.
Reply

Marsh Posté le 07-04-2005 à 09:31:16   

Reply

Marsh Posté le 07-04-2005 à 09:56:30    

Et pourquoi le probleme viendrai de linux [:benou]

Reply

Marsh Posté le 07-04-2005 à 09:58:30    

je suis ouvert à toute proposition :D
 
mais je ne vois pas d'où ca viendrait sinon.
 
GNU/ peut etre :D


---------------
Le droit à la différence s'arrête là où ça commence à m'emmerder sérieusement.
Reply

Marsh Posté le 07-04-2005 à 10:03:19    

En lisant le titre je me suis demandé si tu t'échauffais pour demain :D
 
Vérifie tes cartes réseau voir si il y a pas des paquets qui se font caca dessus.


---------------
uptime is for lousy system administrators what Viagra is for impotent people - mes unixeries - github me
Reply

Marsh Posté le 07-04-2005 à 10:12:16    

:D j'ai bien fait de poster aujourd hui alors :D
 
d'après phpsysinfo, je n'ai aucun err/drop.
 
j'ai pas trop envie de redemarrer mais est ce que ca pourrais jouer ?


---------------
Le droit à la différence s'arrête là où ça commence à m'emmerder sérieusement.
Reply

Marsh Posté le 07-04-2005 à 10:13:18    

Parfois, oui. :o


---------------
Membre du Front de Libération de Datoune | Soutenez le FLD | A Tribute To Datoune
Reply

Marsh Posté le 07-04-2005 à 10:21:01    

Et dans les logs ? :o

Reply

Marsh Posté le 07-04-2005 à 11:58:13    

dans /var/log/messages j'ai plein de :
 

Citation :

Apr  7 10:47:28 serveur -- MARK --


 
dans kern.log, j'ai qq :
 

Citation :

Apr  3 22:54:48 serveur kernel: sending pkt_too_big to self


 
dans syslog, j'ai 2 :
 

Citation :

Apr  7 07:47:51 serveur kernel: UDP: short packet: 44165/27


 
je ne sais pas trop ce que c'est.
 
sinon, si je dois rebooter ( :'( ) je referais toute la machine en sarge. mon bel uptime ...


---------------
Le droit à la différence s'arrête là où ça commence à m'emmerder sérieusement.
Reply

Marsh Posté le 07-04-2005 à 12:02:09    

black_lord a écrit :

En lisant le titre je me suis demandé si tu t'échauffais pour demain :D
 
Vérifie tes cartes réseau voir si il y a pas des paquets qui se font caca dessus.


 
Pourquoi? qu'est-ce qu'il y a demain ?
 
Par contre je vois pas en quoi le fait de redémarrrer pourrait arangner les choses.
 
Mais c'est vrai aussi que je ne vois pas ce qui pourrait poser problème.

Reply

Marsh Posté le 07-04-2005 à 12:02:32    

les --MARK-- c'est normal, ton kernel indique qu'il est toujours en vie :D
 
par contre les 2 autres... c'est moins bon signe. Tu as essayé de claquer le message dans google ?


---------------
uptime is for lousy system administrators what Viagra is for impotent people - mes unixeries - github me
Reply

Marsh Posté le 07-04-2005 à 12:02:32   

Reply

Marsh Posté le 07-04-2005 à 12:04:25    

au fait, mon serveur s'appele "serveur" :D
 
et pour yupo> Vendredy c'est trolly :p !!


---------------
Le droit à la différence s'arrête là où ça commence à m'emmerder sérieusement.
Reply

Marsh Posté le 07-04-2005 à 12:08:07    

les pkt_too_big to self sont pas méchants d'après google.
 
le short packet, j'en sais rien. :|


---------------
Le droit à la différence s'arrête là où ça commence à m'emmerder sérieusement.
Reply

Marsh Posté le 07-04-2005 à 15:37:34    

As-tu vérifié qu'aucun filesystem n'approche de la saturation .

Reply

Marsh Posté le 07-04-2005 à 15:57:58    

Citation :

/dev/hda1              7052024    610576   6083204  10% /
/dev/hda2             11535376   5219288   5730120  48% /home
/dev/hdb1            118729904 104157236   8541468  93% /home/public


 
trop just' ?


---------------
Le droit à la différence s'arrête là où ça commence à m'emmerder sérieusement.
Reply

Marsh Posté le 07-04-2005 à 19:36:40    

tu as check les caches ? etc ...
 
un redémarrage du service samba apporte-il une solution ?


---------------
Mandriva : parce que nous le valons bien ! http://linux-wizard.net/index.php
Reply

Marsh Posté le 07-04-2005 à 19:44:28    

c'est ptetre ton graveur qui est mort aussi  [:chacal_one333]

Reply

Marsh Posté le 07-04-2005 à 19:59:01    

le graveur va bien, qd je grave depuis le disque local je n'ai pas de soucis.
 
DS>les caches de quoi ?
 
je n'avais pas pensé à redemmarer samba, je le fais de ce pas :D


---------------
Le droit à la différence s'arrête là où ça commence à m'emmerder sérieusement.
Reply

Marsh Posté le 07-04-2005 à 20:21:49    

j'ai redémarré samba, sans succès. je suis en train de graver et les buffers font du yoyo. ca fait 17min que ca grave et j'en suis a 50%. pour 4.2Go à 4x c'est pas la joie.
 
help :o


---------------
Le droit à la différence s'arrête là où ça commence à m'emmerder sérieusement.
Reply

Marsh Posté le 07-04-2005 à 22:33:26    

Et le transfert de fichier vers le disque dur de ton PC, ça va vite ou pas ?
(est-ce que c'est le transfert qui est lent, ou juste la gravure ??)
 
Edit: Ca n'a peut être rien à voir avec toi, mais j'ai déja observé une extrême lenteur de mon disque dur (ext3 ou reiserfs) sur des fichiers provenant d'un logiciel à base d'ane (ou de mule). Les fichiers reçus étaient excessivement fragmentés, d'où lenteur atroce. En les déplaçant sur une autre partition, no soucy, ils étaient remis d'équerre.


Message édité par [Albator] le 07-04-2005 à 22:34:53
Reply

Marsh Posté le 07-04-2005 à 22:37:13    

saleté d'animal. c'est bien possible :D
y aurait il un defrag ? :D (je croyais que c'était inutile)
 
faudrait que je refasse des tests de perfs en transfert ftp aussi.


---------------
Le droit à la différence s'arrête là où ça commence à m'emmerder sérieusement.
Reply

Marsh Posté le 07-04-2005 à 22:42:19    

/dev/hdb1 has gone 480 days without being checked, check forced.
 
ca lui fera pas de mal :D


---------------
Le droit à la différence s'arrête là où ça commence à m'emmerder sérieusement.
Reply

Marsh Posté le 07-04-2005 à 22:42:34    

tu peux faire un file system check (fsck) mais ça ne fait "que" mettre ton disque dans un état cohérent,
je ne pense pas que ça résoudra ton problème mais c'est bien utile si il tourne depuis longtemps.

Reply

Marsh Posté le 07-04-2005 à 22:42:58    

j'ai un uptime de 311 jours.


---------------
Le droit à la différence s'arrête là où ça commence à m'emmerder sérieusement.
Reply

Marsh Posté le 07-04-2005 à 22:43:07    

grilled  :D


Message édité par Spy-master le 07-04-2005 à 22:43:35
Reply

Marsh Posté le 07-04-2005 à 22:53:13    

Citation :

serveur:~# e2fsck /dev/hdb1
e2fsck 1.27 (8-Mar-2002)
/dev/hdb1 has gone 480 days without being checked, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
/lost+found not found.  Create<y>? yes
 
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong for group #26 (2613, counted=2612).
Fix<y>? yes
 
Free blocks count wrong (5166400, counted=5166399).
Fix<y>? yes
 
Free inodes count wrong for group #0 (16374, counted=16373).
Fix<y>? yes
 
Directories count wrong for group #0 (1, counted=2).
Fix<y>? yes
 
Free inodes count wrong (15073744, counted=15073743).
Fix<y>? yes
 
 
/dev/hdb1: ***** FILE SYSTEM WAS MODIFIED *****
/dev/hdb1: 15921/15089664 files (6.7% non-contiguous), 24989606/30156005 blocks


 
qq1 peut me faire une explication de texte ? :d je ne sais pas si j'ai bien fait de répondre yes partout  [:crokychips]


---------------
Le droit à la différence s'arrête là où ça commence à m'emmerder sérieusement.
Reply

Marsh Posté le 07-04-2005 à 23:07:30    

je viens de faire des tests en ftp.
le serveur a un serveur ftp et le client est smartftp sur mon XP.
 
résultats minables : 1200KB/s dans un sens et 1500KB/s dans l'autre. bouuuu c'est nul.
le disque est bien en udma5.
je n'ai pas testé l'autre disque du serveur ( / )
 
edit: je fait du 9Mo/s par samba. dans le sens xp => debian. mais qu'est ce que c'est que ce serveur ...


Message édité par Zaib3k le 07-04-2005 à 23:12:30

---------------
Le droit à la différence s'arrête là où ça commence à m'emmerder sérieusement.
Reply

Marsh Posté le 07-04-2005 à 23:22:41    

hdparm -t ?


---------------
uptime is for lousy system administrators what Viagra is for impotent people - mes unixeries - github me
Reply

Marsh Posté le 07-04-2005 à 23:32:20    

9 Mo/s = 72 Mbit/s, soit pas si loin de la limite d'un réseau 100 Mb... pour peu que le routeur ou réseau soit surchargé... enfin, je ne le pense pas, mais si ça peut donner des idées... ;)

Reply

Marsh Posté le 07-04-2005 à 23:45:27    

Peut-être redémarrer le réseau sur le serveur ( /etc/init.d/networking restart )  :??:


---------------
THRAK (def.) : 1) A sudden and precise impact moving from intention, direction and commitment, in service of an aim. 2) 117 guitars almost striking the same chord simultaneously.
Reply

Marsh Posté le 08-04-2005 à 00:24:05    

Vérifier les cables réseaux. Si si, j'avais un débit de merde entre mes pc et c'était du à un câble qui avait décidé de devenir défectueux.

Reply

Marsh Posté le 08-04-2005 à 02:19:28    

sur le serveur : grep socket /etc/samba/smb.conf
 
la taille du fifo pour la gravue sur ta machine ?
 
ça peut jouer...

Reply

Marsh Posté le 08-04-2005 à 10:22:24    


 

Citation :

serveur:~# hdparm -tT /dev/hda && hdparm -tT /dev/hdb
 
/dev/hda:
 Timing buffer-cache reads:   128 MB in  0.34 seconds =376.47 MB/sec
 Timing buffered disk reads:  64 MB in  1.49 seconds = 42.95 MB/sec
 
/dev/hdb:
 Timing buffer-cache reads:   128 MB in  0.36 seconds =355.56 MB/sec
 Timing buffered disk reads:  64 MB in  1.48 seconds = 43.24 MB/sec



---------------
Le droit à la différence s'arrête là où ça commence à m'emmerder sérieusement.
Reply

Marsh Posté le 08-04-2005 à 10:24:00    

BMOTheKiller a écrit :

sur le serveur : grep socket /etc/samba/smb.conf
 
la taille du fifo pour la gravue sur ta machine ?
 
ça peut jouer...


Citation :


serveur:~# grep socket /etc/samba/smb.conf
   socket options = TCP_NODELAY


 
mon graveur a un cache de 2Mo
 
 
sinon, qq1 a une idée à propos de la différence de perfs entre les transferts par ftp et ceux par samba ?


Message édité par Zaib3k le 08-04-2005 à 10:25:50

---------------
Le droit à la différence s'arrête là où ça commence à m'emmerder sérieusement.
Reply

Marsh Posté le 08-04-2005 à 10:38:09    

2 Mo sur le graveur + les 4 Mo par défaut du fifo
 
tente ceci sur le serveur samba :
 
socket options = TCP_NODELAY IPTOS_LOWDELAY SO_SNDBUF=8192 SO_RCVBUF=8192 SO_KEEPALIVE
 
il faut voir aussi si ton serveur samba est chargé (beaucoup de connexions simultanées), dans ce cas le keepalive n'est peut-être pas une bonne idée
 
pour le FTP ça ressemble à une limite de débit :
 
- quel serveur FTP ?
- as-tu vérifié la config pour ton compte sur le serveur ?
- n'as-tu pas une limite activée dans ton client FTP ?
- si tu utilises un autre client c'est pareil ?
- ça donne quoi un scp (winscp) ?
 

Reply

Marsh Posté le 08-04-2005 à 10:49:48    

je vais tenter la modif de socket option. Néanmoins, pourquoi est ce que ca changerais qqc ? puisque les transferts par l'explorateur windows sont performants et stables.
 
le serveur n'est pas chargé du tout, je suis seul dessus et en dehors du transfert pour graver, il n'y a que (dans le pire des cas) de la lecture mp3 et/ou de l'âne qui tourne en plus.
 
pour le ftp, j'utilise vsftpd
je viens de regarder ma conf et les valeurs par defaut de la confi (cf man) et je n'ai pas de limites.
pas de limites sur le client
je testerai avec scp.
 
Merci


---------------
Le droit à la différence s'arrête là où ça commence à m'emmerder sérieusement.
Reply

Marsh Posté le 08-04-2005 à 10:52:07    

Zaib3k a écrit :

je vais tenter la modif de socket option. Néanmoins, pourquoi est ce que ca changerais qqc ? puisque les transferts par l'explorateur windows sont performants et stables.

Parce que le code qui sert à envoyer est différent du code qui sert à recevoir ?


---------------
"The marketing guys said the HP-35 would be a failure because it was too small, and then we couldn't make them fast enough to meet the demand. The marketing folks don't know everything." - Bill Hewlett
Reply

Marsh Posté le 08-04-2005 à 11:14:33    

YupYup a écrit :

Parce que le code qui sert à envoyer est différent du code qui sert à recevoir ?


 
les transferts par samba et l'explorateur de windows sont performants dans les 2 sens.


---------------
Le droit à la différence s'arrête là où ça commence à m'emmerder sérieusement.
Reply

Marsh Posté le 08-04-2005 à 11:19:05    

en scp, les transferts sont aussi nuls qu'en ftp. 1500ko/s en moyenne dans les 2 sens.
 
je pige plus rien.


---------------
Le droit à la différence s'arrête là où ça commence à m'emmerder sérieusement.
Reply

Marsh Posté le 08-04-2005 à 11:26:35    

Zaib3k a écrit :

les transferts par samba et l'explorateur de windows sont performants dans les 2 sens.

Est-ce que j'ai parlé de transferts ? :)


---------------
"The marketing guys said the HP-35 would be a failure because it was too small, and then we couldn't make them fast enough to meet the demand. The marketing folks don't know everything." - Bill Hewlett
Reply

Marsh Posté le 08-04-2005 à 11:27:14    

Claque nous un 2.6.11.7 de derrière les fagots :o
 
Evidemement pour l'uptime... mais bon tu n'est pas complexé par popol ?

Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

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