donc, si je comprends bien, il m'est jste possible d'acheter un barette
DIMM DDR Synchronous 667 MHz (1,5 ns) de 1 Go pour porter à 2 Go ma RAM,
c'est bien ça ???
Est-ce utile ???
J'ai réglé le problème depuis longtemps (10 ans). Une seule partition / Sauvegarde quotidienne des /home/ sur disque externe.
C'est toujours beaucoup plus pratique d'avoir un /home séparé. Ça permet entre autre de réinstaller le système (voire même changer de distribution) sans devoir migrer les données (bien entendu ça ne dispense pas de faire des sauvegardes).
-- Le travail est la malédiction des classes qui boivent. O. Wilde.
Le Thu, 08 Dec 2011 17:34:28 +0000, Arol a écrit:
J'ai réglé le problème depuis longtemps (10 ans). Une seule partition /
Sauvegarde quotidienne des /home/ sur disque externe.
C'est toujours beaucoup plus pratique d'avoir un /home séparé. Ça permet
entre autre de réinstaller le système (voire même changer de
distribution) sans devoir migrer les données (bien entendu ça ne dispense
pas de faire des sauvegardes).
--
Le travail est la malédiction des classes qui boivent.
O. Wilde.
J'ai réglé le problème depuis longtemps (10 ans). Une seule partition / Sauvegarde quotidienne des /home/ sur disque externe.
C'est toujours beaucoup plus pratique d'avoir un /home séparé. Ça permet entre autre de réinstaller le système (voire même changer de distribution) sans devoir migrer les données (bien entendu ça ne dispense pas de faire des sauvegardes).
-- Le travail est la malédiction des classes qui boivent. O. Wilde.
Arol
Le Fri, 09 Dec 2011 07:55:14 +0000, Emmanuel Florac a écrit:
J'ai réglé le problème depuis longtemps (10 ans). Une seule partition / Sauvegarde quotidienne des /home/ sur disque externe.
C'est toujours beaucoup plus pratique d'avoir un /home séparé. Ça permet entre autre de réinstaller le système (voire même changer de distribution) sans devoir migrer les données (bien entendu ça ne dispense pas de faire des sauvegardes).
ça dépend quelles sont tes occupations dans la vie. Si ton but est de passer des heures à faire n'importe quoi pour le fun de geeker, pourquoi pas. Si ton but est d'avoir un truc qui marche sans y passer des heures, il y a pas 36 solutions. En ce moment l'évolution de ubuntu ne me plaît du tout, donc je regarde à gauche à droite de nouvelles distribs dans des machines virtuelles. Quand une me plaira, je réinstallerai de zéro, sachant que la dernière fois que j'ai installé remonte à 5 ans. Donc bon découper son disque en 10 pour gagner 1h (le temps de copier mon /home/) en 5 ans, c'est ridicule, ou un truc de geek.
Le Fri, 09 Dec 2011 07:55:14 +0000, Emmanuel Florac a écrit:
J'ai réglé le problème depuis longtemps (10 ans). Une seule partition /
Sauvegarde quotidienne des /home/ sur disque externe.
C'est toujours beaucoup plus pratique d'avoir un /home séparé. Ça permet
entre autre de réinstaller le système (voire même changer de
distribution) sans devoir migrer les données (bien entendu ça ne
dispense pas de faire des sauvegardes).
ça dépend quelles sont tes occupations dans la vie.
Si ton but est de passer des heures à faire n'importe quoi pour le fun de
geeker, pourquoi pas.
Si ton but est d'avoir un truc qui marche sans y passer des heures, il y
a pas 36 solutions.
En ce moment l'évolution de ubuntu ne me plaît du tout, donc je regarde à
gauche à droite de nouvelles distribs dans des machines virtuelles.
Quand une me plaira, je réinstallerai de zéro, sachant que la dernière
fois que j'ai installé remonte à 5 ans. Donc bon découper son disque en
10 pour gagner 1h (le temps de copier mon /home/) en 5 ans, c'est
ridicule, ou un truc de geek.
Le Fri, 09 Dec 2011 07:55:14 +0000, Emmanuel Florac a écrit:
J'ai réglé le problème depuis longtemps (10 ans). Une seule partition / Sauvegarde quotidienne des /home/ sur disque externe.
C'est toujours beaucoup plus pratique d'avoir un /home séparé. Ça permet entre autre de réinstaller le système (voire même changer de distribution) sans devoir migrer les données (bien entendu ça ne dispense pas de faire des sauvegardes).
ça dépend quelles sont tes occupations dans la vie. Si ton but est de passer des heures à faire n'importe quoi pour le fun de geeker, pourquoi pas. Si ton but est d'avoir un truc qui marche sans y passer des heures, il y a pas 36 solutions. En ce moment l'évolution de ubuntu ne me plaît du tout, donc je regarde à gauche à droite de nouvelles distribs dans des machines virtuelles. Quand une me plaira, je réinstallerai de zéro, sachant que la dernière fois que j'ai installé remonte à 5 ans. Donc bon découper son disque en 10 pour gagner 1h (le temps de copier mon /home/) en 5 ans, c'est ridicule, ou un truc de geek.
denis.paris
Le 08/12/2011 20:20, Eric Masson a écrit :
"denis.paris" writes:
'Lut,
OK, mais ce n'est pas une configuration très courante, Windows ne permettant pas de booter en GPT.
Ce n'est pas ce que dit la source suivante : msdn.microsoft.com/en-us/windows/hardware/gg463525
Il faut une machine uefi et une version 64 bits, certes, mais à partir de Vista, on peut booter depuis un disque GPT.
En linux oui, mais qui en a vraiment besoin?
Ben, ceux qui ont des besoins en taille de partition qui ne sont pas couverts par MBR, ceux qui ont besoin d'un grand nombre de partitions sur leur disque et ne veulent pas se fader un hack moisi (les étendues de MBR), et enfin ceux qui ne veulent pas perdre de données suite à la corruption de la table de partionnement...
Bref, bien peu de raisons, comme on peut le voir.
+1, c'est en effet très loin des préoccupations de l'immense majorité des utilisateurs.
Le 08/12/2011 20:20, Eric Masson a écrit :
"denis.paris"<denis.paris@free.fr> writes:
'Lut,
OK, mais ce n'est pas une configuration très courante, Windows ne
permettant pas de booter en GPT.
Ce n'est pas ce que dit la source suivante :
msdn.microsoft.com/en-us/windows/hardware/gg463525
Il faut une machine uefi et une version 64 bits, certes, mais à partir
de Vista, on peut booter depuis un disque GPT.
En linux oui, mais qui en a vraiment besoin?
Ben, ceux qui ont des besoins en taille de partition qui ne sont pas
couverts par MBR, ceux qui ont besoin d'un grand nombre de partitions
sur leur disque et ne veulent pas se fader un hack moisi (les étendues
de MBR), et enfin ceux qui ne veulent pas perdre de données suite à la
corruption de la table de partionnement...
Bref, bien peu de raisons, comme on peut le voir.
+1, c'est en effet très loin des préoccupations de l'immense majorité
des utilisateurs.
OK, mais ce n'est pas une configuration très courante, Windows ne permettant pas de booter en GPT.
Ce n'est pas ce que dit la source suivante : msdn.microsoft.com/en-us/windows/hardware/gg463525
Il faut une machine uefi et une version 64 bits, certes, mais à partir de Vista, on peut booter depuis un disque GPT.
En linux oui, mais qui en a vraiment besoin?
Ben, ceux qui ont des besoins en taille de partition qui ne sont pas couverts par MBR, ceux qui ont besoin d'un grand nombre de partitions sur leur disque et ne veulent pas se fader un hack moisi (les étendues de MBR), et enfin ceux qui ne veulent pas perdre de données suite à la corruption de la table de partionnement...
Bref, bien peu de raisons, comme on peut le voir.
+1, c'est en effet très loin des préoccupations de l'immense majorité des utilisateurs.
denis.paris
Le 09/12/2011 08:45, Emmanuel Florac a écrit :
Le Thu, 08 Dec 2011 14:57:24 +0100, Damien Wyart a écrit:
Ceci dit, j'avais galement lu un message sur la liste noyau (pas réussi à le retrouver malgré pas mal de googlage) indiquant un meilleur (je ne me souviens plus dans quel sens précis) comportement avec un swap petit (environ 150 Mo) qu'avec un swap de plusieurs Go, sur une machine bien dotée en RAM. C'tait écrit par un dveloppeur reconnu (pas juste un lurkeur qui passait), donc j'y avais apporté un certain crédit.
En fait il faut bien garder à l'esprit que la RAM des machines actuelles est 1000 fois plus grande que celles d'il y a 20 ans (4Go contre 4Mo), par contre le swap sur disque n'a pas tellement accéléré. En 1992 sur un PC avec 4 Mo de RAM et 8 Mo de swap, le disque 120 Mo de l'époque ne mettait au plus qu'une dizaine de secondes pour basculer toute la RAM en swap ou vice-versa. Aujourd'hui, si tu as 4 Go de RAM et 8 Go de swap, un disque tournant mettra au mieux 2 minutes pour basculer toute la RAM en swap ou retour; seul un SSD permettra de s'approcher des durées qu'on avait il y a 20 ans. En effet alors que la RAM est 1000 fois plus grosse, les disques ne sont que 10 fois plus rapides...
De fait, il y a 20 ans un swap de taille importante _par_rapport_à_ _la_ram_ n'était pas un inconvénient grave, parce que les aller-retours RAM/swap prenaient généralement quelques secondes, au pire quelques minutes; aujourd'hui, si une machine avec 2 ou 4 Go de RAM se met à swapper vraiment, elle devient quasi inutilisable pour de longues minutes si ce n'est des heures entières (cas vécu sur une machine avec 8 Go de RAM et 16 Go de swap: machine inutilisable pendant 24 heures à cause d'une fuite mémoire).
L'intérêt d'un swap réduit est donc de permettre au noyau de basculer sur disque les pages vraiment inutilisées; par contre si le swap est vraiment plus petit que la RAM, on est sûr de ne pas risquer de tomber dans un cycle mortel de swapping furieux, comme ça m'est parfois arrivé avec des programmes ayant des fuites mémoire.
D'ailleurs à l'époque de Firefox 3 j'avais carrément désactivé le swap de mon PC pour cette raison: je préfère que le OOM-killer ferme brutalement firefox plutôt que de voir le PC partir en vrille pendant 45 minutes ou plus...
Merci de cette contribution, je trouve que c'est une très bonne remarque.
D'où l’intérêt des petits swap, et d'une RAM dimensionnée pour les besoins réels des applis, + une marge pour permettre l'utilisation en cache disque.
Il faut tout de même garder un swap, même modeste car j'ai lu quelque part (je n'ai pas de références précises) que tous les systèmes avaient besoin d'un espace temporaire externe à la RAM afin de réorganiser "à la volée" son contenu et optimiser son fonctionnement.
Le 09/12/2011 08:45, Emmanuel Florac a écrit :
Le Thu, 08 Dec 2011 14:57:24 +0100, Damien Wyart a écrit:
Ceci dit, j'avais galement lu un message sur la liste noyau (pas réussi
à le retrouver malgré pas mal de googlage) indiquant un meilleur (je ne
me souviens plus dans quel sens précis) comportement avec un swap petit
(environ 150 Mo) qu'avec un swap de plusieurs Go, sur une machine bien
dotée en RAM. C'tait écrit par un dveloppeur reconnu (pas juste un
lurkeur qui passait), donc j'y avais apporté un certain crédit.
En fait il faut bien garder à l'esprit que la RAM des machines actuelles
est 1000 fois plus grande que celles d'il y a 20 ans (4Go contre 4Mo),
par contre le swap sur disque n'a pas tellement accéléré. En 1992 sur un
PC avec 4 Mo de RAM et 8 Mo de swap, le disque 120 Mo de l'époque ne
mettait au plus qu'une dizaine de secondes pour basculer toute la RAM en
swap ou vice-versa. Aujourd'hui, si tu as 4 Go de RAM et 8 Go de swap, un
disque tournant mettra au mieux 2 minutes pour basculer toute la RAM en
swap ou retour; seul un SSD permettra de s'approcher des durées qu'on
avait il y a 20 ans. En effet alors que la RAM est 1000 fois plus grosse,
les disques ne sont que 10 fois plus rapides...
De fait, il y a 20 ans un swap de taille importante _par_rapport_à_
_la_ram_ n'était pas un inconvénient grave, parce que les aller-retours
RAM/swap prenaient généralement quelques secondes, au pire quelques
minutes; aujourd'hui, si une machine avec 2 ou 4 Go de RAM se met à
swapper vraiment, elle devient quasi inutilisable pour de longues minutes
si ce n'est des heures entières (cas vécu sur une machine avec 8 Go de
RAM et 16 Go de swap: machine inutilisable pendant 24 heures à cause
d'une fuite mémoire).
L'intérêt d'un swap réduit est donc de permettre au noyau de basculer sur
disque les pages vraiment inutilisées; par contre si le swap est vraiment
plus petit que la RAM, on est sûr de ne pas risquer de tomber dans un
cycle mortel de swapping furieux, comme ça m'est parfois arrivé avec des
programmes ayant des fuites mémoire.
D'ailleurs à l'époque de Firefox 3 j'avais carrément désactivé le swap de
mon PC pour cette raison: je préfère que le OOM-killer ferme brutalement
firefox plutôt que de voir le PC partir en vrille pendant 45 minutes ou
plus...
Merci de cette contribution, je trouve que c'est une très bonne remarque.
D'où l’intérêt des petits swap, et d'une RAM dimensionnée pour les
besoins réels des applis, + une marge pour permettre l'utilisation en
cache disque.
Il faut tout de même garder un swap, même modeste car j'ai lu quelque
part (je n'ai pas de références précises) que tous les systèmes avaient
besoin d'un espace temporaire externe à la RAM afin de réorganiser "à la
volée" son contenu et optimiser son fonctionnement.
Le Thu, 08 Dec 2011 14:57:24 +0100, Damien Wyart a écrit:
Ceci dit, j'avais galement lu un message sur la liste noyau (pas réussi à le retrouver malgré pas mal de googlage) indiquant un meilleur (je ne me souviens plus dans quel sens précis) comportement avec un swap petit (environ 150 Mo) qu'avec un swap de plusieurs Go, sur une machine bien dotée en RAM. C'tait écrit par un dveloppeur reconnu (pas juste un lurkeur qui passait), donc j'y avais apporté un certain crédit.
En fait il faut bien garder à l'esprit que la RAM des machines actuelles est 1000 fois plus grande que celles d'il y a 20 ans (4Go contre 4Mo), par contre le swap sur disque n'a pas tellement accéléré. En 1992 sur un PC avec 4 Mo de RAM et 8 Mo de swap, le disque 120 Mo de l'époque ne mettait au plus qu'une dizaine de secondes pour basculer toute la RAM en swap ou vice-versa. Aujourd'hui, si tu as 4 Go de RAM et 8 Go de swap, un disque tournant mettra au mieux 2 minutes pour basculer toute la RAM en swap ou retour; seul un SSD permettra de s'approcher des durées qu'on avait il y a 20 ans. En effet alors que la RAM est 1000 fois plus grosse, les disques ne sont que 10 fois plus rapides...
De fait, il y a 20 ans un swap de taille importante _par_rapport_à_ _la_ram_ n'était pas un inconvénient grave, parce que les aller-retours RAM/swap prenaient généralement quelques secondes, au pire quelques minutes; aujourd'hui, si une machine avec 2 ou 4 Go de RAM se met à swapper vraiment, elle devient quasi inutilisable pour de longues minutes si ce n'est des heures entières (cas vécu sur une machine avec 8 Go de RAM et 16 Go de swap: machine inutilisable pendant 24 heures à cause d'une fuite mémoire).
L'intérêt d'un swap réduit est donc de permettre au noyau de basculer sur disque les pages vraiment inutilisées; par contre si le swap est vraiment plus petit que la RAM, on est sûr de ne pas risquer de tomber dans un cycle mortel de swapping furieux, comme ça m'est parfois arrivé avec des programmes ayant des fuites mémoire.
D'ailleurs à l'époque de Firefox 3 j'avais carrément désactivé le swap de mon PC pour cette raison: je préfère que le OOM-killer ferme brutalement firefox plutôt que de voir le PC partir en vrille pendant 45 minutes ou plus...
Merci de cette contribution, je trouve que c'est une très bonne remarque.
D'où l’intérêt des petits swap, et d'une RAM dimensionnée pour les besoins réels des applis, + une marge pour permettre l'utilisation en cache disque.
Il faut tout de même garder un swap, même modeste car j'ai lu quelque part (je n'ai pas de références précises) que tous les systèmes avaient besoin d'un espace temporaire externe à la RAM afin de réorganiser "à la volée" son contenu et optimiser son fonctionnement.
Marc Boyer
Le 09-12-2011, Emmanuel Florac a écrit :
Le Thu, 08 Dec 2011 15:44:48 +0000, Marc Boyer a écrit:
Mais si la somme des applis actives demandent plus de mémoire que la RAM, le système va passer son temps à copier de la RAM vers le swap, du swap vers la RAM, et ça rame affreusement.
En fait ça rame tellement que la machine devient absolument inutilisable (souris et clavier qui ne répondent qu'avec 10 secondes de délai, etc).
Ca m'a toujours étonné que le scheduler ne sache pas par défaut se sortir de se genre de choses: diminuer la priorité des process qui swapent, augmenter la priorité des moyens de connection (ssh, consoles)...
Marc Boyer -- À mesure que les inégalités regressent, les attentes se renforcent. François Dubet
Le 09-12-2011, Emmanuel Florac <eflorac@imaginet.fr> a écrit :
Le Thu, 08 Dec 2011 15:44:48 +0000, Marc Boyer a écrit:
Mais si la somme des applis actives demandent
plus de mémoire que la RAM, le système va passer son temps à copier de
la RAM vers le swap, du swap vers la RAM, et ça rame affreusement.
En fait ça rame tellement que la machine devient absolument inutilisable
(souris et clavier qui ne répondent qu'avec 10 secondes de délai, etc).
Ca m'a toujours étonné que le scheduler ne sache pas par défaut se
sortir de se genre de choses: diminuer la priorité des process qui swapent,
augmenter la priorité des moyens de connection (ssh, consoles)...
Marc Boyer
--
À mesure que les inégalités regressent, les attentes se renforcent.
François Dubet
Le Thu, 08 Dec 2011 15:44:48 +0000, Marc Boyer a écrit:
Mais si la somme des applis actives demandent plus de mémoire que la RAM, le système va passer son temps à copier de la RAM vers le swap, du swap vers la RAM, et ça rame affreusement.
En fait ça rame tellement que la machine devient absolument inutilisable (souris et clavier qui ne répondent qu'avec 10 secondes de délai, etc).
Ca m'a toujours étonné que le scheduler ne sache pas par défaut se sortir de se genre de choses: diminuer la priorité des process qui swapent, augmenter la priorité des moyens de connection (ssh, consoles)...
Marc Boyer -- À mesure que les inégalités regressent, les attentes se renforcent. François Dubet
Eric Masson
"denis.paris" writes:
Bref, bien peu de raisons, comme on peut le voir.
+1, c'est en effet très loin des préoccupations de l'immense majorité des utilisateurs.
La remarque en question était bien entendu ironique... Le schéma de partionnement MBR est une saleté qui aurait du disparaitre depuis longtemps, la résistance au changement du marché PC est assez étonnante.
-- CF : Tu vois l'intérêt d'en faire tourner une sous WinCE ? PAD: L'écran bleu ? SP : Voilà. Une sorte de "Game over" aléatoire, en fait... + SP in Guide du Macounet Pervers : Playstation II c plus fort que toi+
"denis.paris" <denis.paris@free.fr> writes:
Bref, bien peu de raisons, comme on peut le voir.
+1, c'est en effet très loin des préoccupations de l'immense majorité
des utilisateurs.
La remarque en question était bien entendu ironique...
Le schéma de partionnement MBR est une saleté qui aurait du disparaitre
depuis longtemps, la résistance au changement du marché PC est assez
étonnante.
--
CF : Tu vois l'intérêt d'en faire tourner une sous WinCE ?
PAD: L'écran bleu ?
SP : Voilà. Une sorte de "Game over" aléatoire, en fait...
+ SP in Guide du Macounet Pervers : Playstation II c plus fort que toi+
+1, c'est en effet très loin des préoccupations de l'immense majorité des utilisateurs.
La remarque en question était bien entendu ironique... Le schéma de partionnement MBR est une saleté qui aurait du disparaitre depuis longtemps, la résistance au changement du marché PC est assez étonnante.
-- CF : Tu vois l'intérêt d'en faire tourner une sous WinCE ? PAD: L'écran bleu ? SP : Voilà. Une sorte de "Game over" aléatoire, en fait... + SP in Guide du Macounet Pervers : Playstation II c plus fort que toi+
yamo
Salut,
Le Fri, 09 Dec 2011 00:14:29 +0100, NiKo a écrit :
Ou alors, si tu as plusieurs machines à ta disposition, un serveur subversion et un coups de fsvs dans /etc sur la machine à sauvegarder. C'est tip-top, et en plus, ça permets de retrouver les modifs qu'on à pu faire quelques années plus tôt.
Merci beaucoup pour ce message, ça risque de me servir!!!
-- Stéphane <http://pasdenom.info/fortune/> La femme est un roseau dépensant. -+- Jules Renard -+-
Salut,
Le Fri, 09 Dec 2011 00:14:29 +0100, NiKo a écrit :
Ou alors, si tu as plusieurs machines à ta disposition, un serveur
subversion et un coups de fsvs dans /etc sur la machine à sauvegarder.
C'est tip-top, et en plus, ça permets de retrouver les modifs qu'on à pu
faire quelques années plus tôt.
Merci beaucoup pour ce message, ça risque de me servir!!!
--
Stéphane <http://pasdenom.info/fortune/>
La femme est un roseau dépensant.
-+- Jules Renard -+-
Le Fri, 09 Dec 2011 00:14:29 +0100, NiKo a écrit :
Ou alors, si tu as plusieurs machines à ta disposition, un serveur subversion et un coups de fsvs dans /etc sur la machine à sauvegarder. C'est tip-top, et en plus, ça permets de retrouver les modifs qu'on à pu faire quelques années plus tôt.
Merci beaucoup pour ce message, ça risque de me servir!!!
-- Stéphane <http://pasdenom.info/fortune/> La femme est un roseau dépensant. -+- Jules Renard -+-
Lucas Levrel
Le 8 décembre 2011, Une Bévue a écrit :
perso j'ai 1 Go de RAM actuellement pour 2 Go de swap
chez moi, ça donne : :~$ free -m total used free shared buffers cached Mem: 991 879 111 0 13 264 -/+ buffers/cache: 601 389 Swap: 1906 177 1729
c'est quelles unités des blocks de 4 ko ???
Vue la colonne « total », 1 ko...
-- LL
Le 8 décembre 2011, Une Bévue a écrit :
perso j'ai 1 Go de RAM actuellement pour 2 Go de swap
chez moi, ça donne :
yt@D620:~$ free -m
total used free shared buffers
cached
Mem: 991 879 111 0 13
264
-/+ buffers/cache: 601 389
Swap: 1906 177 1729
perso j'ai 1 Go de RAM actuellement pour 2 Go de swap
chez moi, ça donne : :~$ free -m total used free shared buffers cached Mem: 991 879 111 0 13 264 -/+ buffers/cache: 601 389 Swap: 1906 177 1729
c'est quelles unités des blocks de 4 ko ???
Vue la colonne « total », 1 ko...
-- LL
denis.paris
Le 08/12/2011 20:28, Une Bévue a écrit :
denis.paris wrote:
Cette règle x2 était valable pour des faibles capacité de RAM, maintenant le swap est beaucoup moins sollicité. SWAP = RAM est une bonne base, pour 2 ou 4 Go, voire moins au delà. Personnellement je limite à 2 Go alors que j'ai 8 Go physique.
perso j'ai 1 Go de RAM actuellement pour 2 Go de swap
Ca dépend bien sûr des applis, si on a un doute faire "free -m" pour voir le swap occupé, en général 0.
chez moi, ça donne : :~$ free -m total used free shared buffers cached Mem: 991 879 111 0 13 264 -/+ buffers/cache: 601 389 Swap: 1906 177 1729
c'est quelles unités des blocks de 4 ko ???
le "m" c'est pour "Mo"
Le 08/12/2011 20:28, Une Bévue a écrit :
denis.paris<denis.paris@free.fr> wrote:
Cette règle x2 était valable pour des faibles capacité de RAM,
maintenant le swap est beaucoup moins sollicité. SWAP = RAM est une
bonne base, pour 2 ou 4 Go, voire moins au delà. Personnellement je
limite à 2 Go alors que j'ai 8 Go physique.
perso j'ai 1 Go de RAM actuellement pour 2 Go de swap
Ca dépend bien sûr des applis, si on a un doute faire "free -m" pour
voir le swap occupé, en général 0.
chez moi, ça donne :
yt@D620:~$ free -m
total used free shared buffers
cached
Mem: 991 879 111 0 13
264
-/+ buffers/cache: 601 389
Swap: 1906 177 1729
Cette règle x2 était valable pour des faibles capacité de RAM, maintenant le swap est beaucoup moins sollicité. SWAP = RAM est une bonne base, pour 2 ou 4 Go, voire moins au delà. Personnellement je limite à 2 Go alors que j'ai 8 Go physique.
perso j'ai 1 Go de RAM actuellement pour 2 Go de swap
Ca dépend bien sûr des applis, si on a un doute faire "free -m" pour voir le swap occupé, en général 0.
chez moi, ça donne : :~$ free -m total used free shared buffers cached Mem: 991 879 111 0 13 264 -/+ buffers/cache: 601 389 Swap: 1906 177 1729
c'est quelles unités des blocks de 4 ko ???
le "m" c'est pour "Mo"
Yliur
Le Fri, 9 Dec 2011 09:29:50 +0000 (UTC) Marc Boyer a écrit :
Le 09-12-2011, Emmanuel Florac a écrit : > Le Thu, 08 Dec 2011 15:44:48 +0000, Marc Boyer a écrit: > >> Mais si la somme des applis actives demandent >> plus de mémoire que la RAM, le système va passer son temps à >> copier de la RAM vers le swap, du swap vers la RAM, et ça rame >> affreusement. > > En fait ça rame tellement que la machine devient absolument > inutilisable (souris et clavier qui ne répondent qu'avec 10 > secondes de délai, etc).
Ca m'a toujours étonné que le scheduler ne sache pas par défaut se sortir de se genre de choses: diminuer la priorité des process qui swapent, augmenter la priorité des moyens de connection (ssh, consoles)...
Marc Boyer
C'est l'éternelle question de "dans quelle mesure le planificateur doit-il savoir ce qu'il manipule ou au contraire être agnostique", non ? Je suppose que lui fournir plus d'informations requiert une architecture plus complexe (pour fournir plus d'information) et un planificateur lui-même plus complexe pour prendre en compte toutes ces informations, ce qui doit avoir des inconvénients (fiabilité, temps d'exécution, moyens de configuration, ... ?).
Par contre il est déjà possible de jouer avec l'existant : les priorités (seul root peut fournir des priorités très élevées par contre, mais s'il s'agit du processus serveur comme ssh ça doit pouvoir s'arranger), le serveur X (quelqu'un parlait de clavier/souris), ... Je pense que si tu mets tout ça en priorité maximale ça devrait rester un peu réactif :) . Sauf qu'en cas de problème dans l'un de ces programmes ça risque de bloquer tout le reste.
Il y a aussi les "cgroups" si je ne m'abuse, un mécanisme qui permet de faire des "quotas" d'utilisation de ressources par groupes. Il doit être possible de mettre tes "moyens de communication" dans un groupe et de dire "si tout le monde se bat pour le processeur, leur en réserver au moins 25%". Je ne sais plus comment on fait en pratique, mais il me semble que c'est à ça que ça sert.
Le Fri, 9 Dec 2011 09:29:50 +0000 (UTC)
Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> a écrit :
Le 09-12-2011, Emmanuel Florac <eflorac@imaginet.fr> a écrit :
> Le Thu, 08 Dec 2011 15:44:48 +0000, Marc Boyer a écrit:
>
>> Mais si la somme des applis actives demandent
>> plus de mémoire que la RAM, le système va passer son temps à
>> copier de la RAM vers le swap, du swap vers la RAM, et ça rame
>> affreusement.
>
> En fait ça rame tellement que la machine devient absolument
> inutilisable (souris et clavier qui ne répondent qu'avec 10
> secondes de délai, etc).
Ca m'a toujours étonné que le scheduler ne sache pas par défaut se
sortir de se genre de choses: diminuer la priorité des process qui
swapent, augmenter la priorité des moyens de connection (ssh,
consoles)...
Marc Boyer
C'est l'éternelle question de "dans quelle mesure le planificateur
doit-il savoir ce qu'il manipule ou au contraire être agnostique",
non ? Je suppose que lui fournir plus d'informations requiert une
architecture plus complexe (pour fournir plus d'information) et un
planificateur lui-même plus complexe pour prendre en compte toutes ces
informations, ce qui doit avoir des inconvénients (fiabilité, temps
d'exécution, moyens de configuration, ... ?).
Par contre il est déjà possible de jouer avec l'existant : les
priorités (seul root peut fournir des priorités très élevées par
contre, mais s'il s'agit du processus serveur comme ssh ça doit
pouvoir s'arranger), le serveur X (quelqu'un parlait de
clavier/souris), ... Je pense que si tu mets tout ça en priorité
maximale ça devrait rester un peu réactif :) . Sauf qu'en cas de
problème dans l'un de ces programmes ça risque de bloquer tout le
reste.
Il y a aussi les "cgroups" si je ne m'abuse, un mécanisme qui permet de
faire des "quotas" d'utilisation de ressources par groupes. Il doit
être possible de mettre tes "moyens de communication" dans un groupe et
de dire "si tout le monde se bat pour le processeur, leur en réserver
au moins 25%". Je ne sais plus comment on fait en pratique, mais il me
semble que c'est à ça que ça sert.
Le Fri, 9 Dec 2011 09:29:50 +0000 (UTC) Marc Boyer a écrit :
Le 09-12-2011, Emmanuel Florac a écrit : > Le Thu, 08 Dec 2011 15:44:48 +0000, Marc Boyer a écrit: > >> Mais si la somme des applis actives demandent >> plus de mémoire que la RAM, le système va passer son temps à >> copier de la RAM vers le swap, du swap vers la RAM, et ça rame >> affreusement. > > En fait ça rame tellement que la machine devient absolument > inutilisable (souris et clavier qui ne répondent qu'avec 10 > secondes de délai, etc).
Ca m'a toujours étonné que le scheduler ne sache pas par défaut se sortir de se genre de choses: diminuer la priorité des process qui swapent, augmenter la priorité des moyens de connection (ssh, consoles)...
Marc Boyer
C'est l'éternelle question de "dans quelle mesure le planificateur doit-il savoir ce qu'il manipule ou au contraire être agnostique", non ? Je suppose que lui fournir plus d'informations requiert une architecture plus complexe (pour fournir plus d'information) et un planificateur lui-même plus complexe pour prendre en compte toutes ces informations, ce qui doit avoir des inconvénients (fiabilité, temps d'exécution, moyens de configuration, ... ?).
Par contre il est déjà possible de jouer avec l'existant : les priorités (seul root peut fournir des priorités très élevées par contre, mais s'il s'agit du processus serveur comme ssh ça doit pouvoir s'arranger), le serveur X (quelqu'un parlait de clavier/souris), ... Je pense que si tu mets tout ça en priorité maximale ça devrait rester un peu réactif :) . Sauf qu'en cas de problème dans l'un de ces programmes ça risque de bloquer tout le reste.
Il y a aussi les "cgroups" si je ne m'abuse, un mécanisme qui permet de faire des "quotas" d'utilisation de ressources par groupes. Il doit être possible de mettre tes "moyens de communication" dans un groupe et de dire "si tout le monde se bat pour le processeur, leur en réserver au moins 25%". Je ne sais plus comment on fait en pratique, mais il me semble que c'est à ça que ça sert.
