From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows 98; Win 9x 4.90) Description of problem: Server samba for about 500 users on a IBM Netfinity 5100 (Bi-PIII 733 / 1Go ECC) After a while we notice slowings down and in the final we arrive on a blocking of the machine and we must reboot the server. Version-Release number of selected component (if applicable): How reproducible: Didn't try Steps to Reproduce: Actual Results: A functioning which degrades in the time. Expected Results: A correct functioning on the duration. Additional info: Here's the top output after 1 month of use : # top 11:21am up 38 days, 18:59, 2 users, load average: 0.10, 0.06, 0.08 338 processes: 337 sleeping, 1 running, 0 zombie, 0 stopped CPU0 states: 3.2% user, 6.0% system, 0.0% nice, 90.1% idle CPU1 states: 2.4% user, 4.0% system, 0.0% nice, 92.4% idle Mem: 1028744K av, 1020348K used, 8396K free, 352K shrd, 41824K buff Swap: 528056K av, 456616K used, 71440K free 458356K cached <...> Sometimes when we watch the activity of the server with vmstat we obtain curious results. In periods, we have a lot of bi (superior to 4000) and practically not of bo (lower than 200) a lot(many). And in the other periods (often when we notice slowings down) a lot of bo (superior to 4000) and practically not of bi (lower than 200) Here's a vmstat output when we have a lot of bi # vmstat -n 1 procs memory swap io system cpu r b w swpd free buff cache si so bi bo in cs us sy id 0 1 0 437540 3060 43120 458500 64 0 6524 0 2858 2656 3 9 88 0 1 0 437540 3060 43192 458268 0 0 5448 0 2534 2787 1 6 93 0 0 0 437492 3060 43208 458008 0 0 6776 0 2575 2653 1 5 94 0 2 1 437480 4040 43228 457168 0 0 7924 192 3645 3832 4 10 86 0 1 0 437364 3056 42756 460092 0 0 9580 244 2889 2807 4 16 80 0 0 0 437096 3540 42772 459852 0 0 9672 12 3402 3276 3 9 89 0 1 0 436920 3060 42600 462020 0 0 9616 0 4461 4280 2 10 88 0 1 0 436252 3060 42612 461176 0 0 7772 0 3443 3344 2 13 85 0 0 0 436252 3060 42648 463056 0 0 9544 248 3407 3146 4 8 88 0 0 0 435984 3056 42652 460692 388 0 5988 144 4533 3964 7 7 86 0 0 0 435948 3216 42672 460520 28 0 6088 144 3916 3501 3 8 89 0 0 0 435944 3440 42672 462412 0 0 1544 484 3921 3847 8 10 82 0 1 0 435476 3248 42500 462844 0 0 6180 160 3685 3158 4 12 84 1 0 0 435476 3060 42520 461128 0 0 8652 12 3306 2866 3 4 93 0 1 0 435224 3056 42512 463232 0 0 7888 268 3587 3130 5 10 85 0 1 0 435220 3060 42528 462932 0 0 7272 248 3828 3537 5 9 86 0 0 0 435220 3060 42512 463176 0 0 6204 43309 2873 1 8 91 Is it going to take out a kernel 2.4.17 in rpm redhat official for 7.1 and 7.2 ?
Okay, let's try to communicate in French a bit to get a precise description. ----------- LANG=fr_FR ------------- Le report semble indiquer que la machine se bloque. Est-ce qu'elle gele completement, ou juste que progressivement les operations deviennent de plus en plus lentes jusqu'au point ou vous decidez de redemarrer le serveur. Je note que les information donnees part top indique que la memoire virtuelle est completement saturee. 500 Mo de swap pour 500 utilisateurs est clairement sous-dimentionne, cela peut generer le genre de probleme que vous observez. Pouvez vous augmenter la taille du swap le cas echeant en rajoutant un fichier de swap. Pouvez vous aussi indiquer les informations de top apres quelques jours d'utilisation et non apres un mois ? Pouvez vous aussi indiquer le type de systeme de fichiers que vous utilisez ? Concernant 2.4.17 ou de maniere general un noyau recent, Red Hat ne le le releasera que lorsqu'il passera les tests de qualites necessaire. ---------------------------------- Daniel Veillard
No, effectively it is not completely freezed, but it is not far. We met several situations, that we can classify in thes 3 cases : 1 - Can not open an session. 2 - Can open an session, but commands do not succeed 3 - Can open an session and commands succeed. In the 3 cases, in the final we reboot the server, but in the first 2 cases Generally the reboot finished badly. Concerning the 512Mo of swap, I found it being enough for a machine with 1Go of RAM. Indeed, 1Go should be enough and we should not overflow so much on the swap. For me, it indicates a kernel problem and moreover vmstat seems to confirm it, because on average we should have an equivalence between bi and bo while we have extremes.
Thanks for the bug report. However, Red Hat no longer maintains this version of the product. Please upgrade to the latest version and open a new bug if the problem persists. The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, and if you believe this bug is interesting to them, please report the problem in the bug tracker at: http://bugzilla.fedora.us/