Re: Informix and Oracle in the same shop
David Williams wrote: > > In article <5n1dv1$2ar@mew.corp.sgi.com>, Pablo Sanchez > <news_reader@mew.corp.sgi.com> writes > > > >In article <33935782.7D9610FC@devnull.org>, Tim Schaefer <devnull@devnull.org> > >writes: > >> Pablo Sanchez wrote: > >> > > >> > No vendor, that I know of, is truly multi-threaded... at least in the > >> > sense of user threads and the like. > >> > -- > >> > >> whoa! > >> > >> Finally somebody mentioned the threads thing, and you shoot it down > >> so quickly! tsk tsk.... :-) > > > >:-)!!!! Well they'll all claim it if it's the soup of the day kinda > >thing... > > > >> Yes, as much as I hammer on Informix, they are truly and independently > >> verified to have multi-threading--unless it's all bs... But Oracle > >> last I heard was multi-process not multi-threaded... > > > >I know that you're statement of "hammer"ing informix is more in jest > >than anything else... I'm not trying to hammer > >informix/sybase/oracle. If you look closely enough, you can find > >enough to hammer any one of them... for that matter, you can find > >something in each to glee over... so with *that* outta da way.... > > > >o Sybase isn't threaded in the sense of user threads as it conducts > > its own type of thread management. IMHO, I believe that the > > threads are too coarse to allow for a true multi-thread execution. > > > I'm not sure about Sybase. > > >o Informix isn't threaded because you have all 'em VP's running out > > there. They aren't in the same execution space. They have their > > own and thus there is *some* context switching. Of course Oracle > > has a process for *everything* so that's taking context switching > > to the max. > > So how do you get >1 CPU used simulatanously if you one have one UNIX > process. Remember UNIX controls **EVERYTHING** even virtualising > memory and I/O port usage. UNIX schedules PROCESSES to run NOT > THREADS. In order to get >1 physical CPU used you must have >1 > process acitve. Hence Informix recommed 1 less CPU VP less than > the number of physical CPUs (to allow other things apart from > Informix to run). > > When doing I/O which is not kernel asychronous I/O than the PROCESS > doing the I/O will be blocked. You don't want all your threads within > that process to stop hence put the I/O thread into it's own process > (AIO VPs). AIO VPs can be only 1 (to write to the online.log message > file which must be a normal UNIX file... > > This is the least number of processes you can run i.e. most multi- > threaded you can get under UNIX. I have seen 130 informix users with > ~10-12 UNIX processes handling all their connections. Proof that > Informix is truely mutli-threadeded..... > > > > >With enough CPU's, though, the context switching isn't as much as an > >issue... IMHO. You can always bind a process to a processor. > >-- > >Pablo Sanchez | wk: 415.933.3812| pg: 800.930.5635 -or- pablo_p@pager.sgi.com > >--------------+-----------------+-------------------------------------------- > >pablo@sgi.com ... when mailing me, place "not spam" in the Subject > > -- > David Williams David Williams wrote: > > In article <5n1dv1$2ar@mew.corp.sgi.com>, Pablo Sanchez > <news_reader@mew.corp.sgi.com> writes > > > >In article <33935782.7D9610FC@devnull.org>, Tim Schaefer <devnull@devnull.org> > >writes: > >> Pablo Sanchez wrote: > >> > > >> > No vendor, that I know of, is truly multi-threaded... at least in the > >> > sense of user threads and the like. > >> > -- > >> > >> whoa! > >> > >> Finally somebody mentioned the threads thing, and you shoot it down > >> so quickly! tsk tsk.... :-) > > > >:-)!!!! Well they'll all claim it if it's the soup of the day kinda > >thing... > > > >> Yes, as much as I hammer on Informix, they are truly and independently > >> verified to have multi-threading--unless it's all bs... But Oracle > >> last I heard was multi-process not multi-threaded... > > > >I know that you're statement of "hammer"ing informix is more in jest > >than anything else... I'm not trying to hammer > >informix/sybase/oracle. If you look closely enough, you can find > >enough to hammer any one of them... for that matter, you can find > >something in each to glee over... so with *that* outta da way.... > > > >o Sybase isn't threaded in the sense of user threads as it conducts > > its own type of thread management. IMHO, I believe that the > > threads are too coarse to allow for a true multi-thread execution. > > > I'm not sure about Sybase. > > >o Informix isn't threaded because you have all 'em VP's running out > > there. They aren't in the same execution space. They have their > > own and thus there is *some* context switching. Of course Oracle > > has a process for *everything* so that's taking context switching > > to the max. > > So how do you get >1 CPU used simulatanously if you one have one UNIX > process. Remember UNIX controls **EVERYTHING** even virtualising > memory and I/O port usage. UNIX schedules PROCESSES to run NOT > THREADS. In order to get >1 physical CPU used you must have >1 > process acitve. Hence Informix recommed 1 less CPU VP less than > the number of physical CPUs (to allow other things apart from > Informix to run). > > When doing I/O which is not kernel asychronous I/O than the PROCESS > doing the I/O will be blocked. You don't want all your threads within > that process to stop hence put the I/O thread into it's own process > (AIO VPs). AIO VPs can be only 1 (to write to the online.log message > file which must be a normal UNIX file... > > This is the least number of processes you can run i.e. most multi- > threaded you can get under UNIX. I have seen 130 informix users with > ~10-12 UNIX processes handling all their connections. Proof that > Informix is truely mutli-threadeded..... > > > > >With enough CPU's, though, the context switching isn't as much as an > >issue... IMHO. You can always bind a process to a processor. > >-- > >Pablo Sanchez | wk: 415.933.3812| pg: 800.930.5635 -or- pablo_p@pager.sgi.com > >--------------+-----------------+-------------------------------------------- > >pablo@sgi.com ... when mailing me, place "not spam" in the Subject > > -- > David Williams Thanks David for clearing this up a bit more... :-) I had to go hunt down my literature to get this abit more documented so I don't just talk through my hat--or Pablos' :-) This guy wrote a very nice report covering the differences of all the major data bases in >>>> 1993 <<<<< : David McGoveran Alternative Technologies 13150 Highway 9, #123 Boulder Creek, CA 95006 408-338-4621 REPORT: "An Evaluation of Database Server Architectures" Version 93.10 His report gave glowing remarks about Informix and a little bit to Sybase, but the beast was clearly the loser. I hope folks can contact this guy to get his latest report, however I have not done so, and am not able to verify if the above address is still accurate.@