RE: IDS, Linux and OOM killer

Hi Philippe, I know very little about linux, but if you can't fix it at the o/s level, maybe you can avoid it at the informix level..... If it only happens every now & then because of the onbar DB backup.....what are your onbar settings.... Maybe if you are running with BAR_MAX in $ONCONFIG set high (i.e. ours is 12) and it is normally ok except sometimes.... maybe bring it down a notch (i.e. in my case I would try 10). If you post your onbar $ONCONFIG settings the community here may have additional insight. Thanks, Norma Jean -----Original Message----- From: informix-list-bounces@iiug.org [mailto:informix-list-bounces@iiug.org] On Behalf Of philippe Sent: Wednesday, November 22, 2006 4:39 AM To: informix-list@iiug.org Subject: IDS, Linux and OOM killer Good morning/evening, We have installed IDS 10.00.UC4 on a Linux box, RedHat Enterprise ES v4. The server has 8Gb RAM and 4Gb swap. IDS uses normally only about 2.5Gb of shared memory. Unfortunately, this nice server is not stable: the linux kernel regularly kills oninit process, throug his 'OOM Killer' mechanism. The server is dedicated to IDS, and the problem occurs when onbar is launched to backup the dbspaces. The backup process runs every night, and the problem occurs about twice a month. We can then see in the 'messages' file: Nov 22 02:10:04 dat5ix kernel: Free swap: 3919176kB Nov 22 02:10:04 dat5ix kernel: 2359296 pages of RAM Nov 22 02:10:04 dat5ix kernel: 1867710 pages of HIGHMEM Nov 22 02:10:04 dat5ix kernel: 282150 reserved pages Nov 22 02:10:04 dat5ix kernel: 2115705 pages shared Nov 22 02:10:04 dat5ix kernel: 48 pages swap cached Nov 22 02:10:04 dat5ix kernel: Out of Memory: Killed process 3953 (oninit). Have you yet experienced such a problem ? If yes, how did you solve it ? We have tried: - setting vm.overcommit_memory = 2 in /etc/sysctl.conf file : no effect - setting RESIDENT 0 in $ONCONFIG file (it was -1 before); this change has been made today; I don't know if it will solve the problem. Thank you for your attention, Philippe Chantry _______________________________________________ Informix-list mailing list Informix-list@iiug.org http://www.iiug.org/mailman/listinfo/informix-list ============================================================ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================

Sebastian, Norma J. avait ï¿œcrit le 22/11/2006 : > Hi Philippe, > > I know very little about linux, but if you can't fix it at the o/s > level, maybe you can avoid it at the informix level..... > > If it only happens every now & then because of the onbar DB > backup.....what are your onbar settings.... Maybe if you are running > with BAR_MAX in $ONCONFIG set high (i.e. ours is 12) and it is normally > ok except sometimes.... maybe bring it down a notch (i.e. in my case I > would try 10). > > If you post your onbar $ONCONFIG settings the community here may have > additional insight. Sebastian, Thank you for your answer. Here are our Onbar settings: they come from onconfig.std file ! BAR_DEBUG 0 BAR_MAX_BACKUP 0 BAR_RETRY 1 BAR_NB_XPORT_COUNT 20 BAR_XFER_BUF_SIZE 31 RESTARTABLE_RESTORE ON BAR_PROGRESS_FREQ 0 We perform whole system backup (onbar -w), so that the backup shoud be processed serially even if BAR_MAX_BACKUP=0. Philippe