Linux s'essoufle avec le temps ? - Divers - Linux et OS Alternatifs
Marsh Posté le 07-04-2005 à 09:58:30
je suis ouvert à toute proposition
mais je ne vois pas d'où ca viendrait sinon.
GNU/ peut etre
Marsh Posté le 07-04-2005 à 10:03:19
En lisant le titre je me suis demandé si tu t'échauffais pour demain
Vérifie tes cartes réseau voir si il y a pas des paquets qui se font caca dessus.
Marsh Posté le 07-04-2005 à 10:12:16
j'ai bien fait de poster aujourd hui alors
d'après phpsysinfo, je n'ai aucun err/drop.
j'ai pas trop envie de redemarrer mais est ce que ca pourrais jouer ?
Marsh Posté le 07-04-2005 à 10:13:18
Parfois, oui.
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 ...
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 |
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.
Marsh Posté le 07-04-2005 à 12:02:32
les --MARK-- c'est normal, ton kernel indique qu'il est toujours en vie
par contre les 2 autres... c'est moins bon signe. Tu as essayé de claquer le message dans google ?
Marsh Posté le 07-04-2005 à 12:04:25
au fait, mon serveur s'appele "serveur"
et pour yupo> Vendredy c'est trolly !!
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. :|
Marsh Posté le 07-04-2005 à 15:37:34
As-tu vérifié qu'aucun filesystem n'approche de la saturation .
Marsh Posté le 07-04-2005 à 15:57:58
Citation : /dev/hda1 7052024 610576 6083204 10% / |
trop just' ?
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 ?
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
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
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.
Marsh Posté le 07-04-2005 à 22:37:13
saleté d'animal. c'est bien possible
y aurait il un defrag ? (je croyais que c'était inutile)
faudrait que je refasse des tests de perfs en transfert ftp aussi.
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
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.
Marsh Posté le 07-04-2005 à 22:42:58
j'ai un uptime de 311 jours.
Marsh Posté le 07-04-2005 à 22:43:07
grilled
Marsh Posté le 07-04-2005 à 22:53:13
Citation : serveur:~# e2fsck /dev/hdb1 |
qq1 peut me faire une explication de texte ? je ne sais pas si j'ai bien fait de répondre yes partout
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 ...
Marsh Posté le 07-04-2005 à 23:22:41
hdparm -t ?
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...
Marsh Posté le 07-04-2005 à 23:45:27
Peut-être redémarrer le réseau sur le serveur ( /etc/init.d/networking restart )
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.
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...
Marsh Posté le 08-04-2005 à 10:22:24
black_lord a écrit : hdparm -t ? |
Citation : serveur:~# hdparm -tT /dev/hda && hdparm -tT /dev/hdb |
Marsh Posté le 08-04-2005 à 10:24:00
BMOTheKiller a écrit : sur le serveur : grep socket /etc/samba/smb.conf |
Citation : |
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 ?
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) ?
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
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 ?
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.
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.
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 ?
Marsh Posté le 08-04-2005 à 11:27:14
Claque nous un 2.6.11.7 de derrière les fagots
Evidemement pour l'uptime... mais bon tu n'est pas complexé par popol ?
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.