4.0.5 omniNames performance patch

Jonathan Biggar <[email protected]> Wed, 03 Aug 2005 14:06:12 -0700
Newsgroups gmane.comp.corba.omniorb.devel
Message-ID <[email protected]>
We discovered that omniNames caused *very* bad performance on a hardware 
RAID5 array if the omniNames error log was stored on the array.  This 
was because it was opening its error log using O_SYNC and unbuffered, 
which tells the kernel to  synchronously flush to the disk *each* 
character written to the log.

I've attached a patch to 4.0.5 that fixes this problem.  (I don't see 
any safety reason why the omniNames error log needs to use O_SYNC or be 
unbuffered anyway...)

-- 
Jon Biggar
Levanta
[email protected]

_______________________________________________
omniORB-dev mailing list
[email protected]
http://www.omniorb-support.com/mailman/listinfo/omniorb-dev
omniORB-omniNames-errlog.patch (text/plain, 709 B)
--- omniORB-4.0.5/src/appl/omniNames/omniNames.cc.orig	2003-05-09 06:32:59.000000000 -0700
+++ omniORB-4.0.5/src/appl/omniNames/omniNames.cc	2005-07-01 14:16:53.000000000 -0700
@@ -150,12 +150,13 @@
       int fd = _open(argv[2], O_WRONLY | O_CREAT | O_TRUNC, _S_IWRITE);
       if (fd < 0 || _dup2(fd,2)) {
 #else
-      int fd = open(argv[2], O_WRONLY | O_CREAT | O_TRUNC | O_SYNC, 0666);
+      int fd = open(argv[2], O_WRONLY | O_CREAT | O_TRUNC, 0666);
       if (fd < 0 || dup2(fd,2) < 0) {
 #endif
 	cerr << "Cannot open error log file: " << argv[2] << endl;
 	usage();
       }
+      setlinebuf(stderr);
       removeArgs(argc, argv, 1, 2);
     }
     else if ((strncmp(argv[1], "-ORB", 4) != 0)) {