RE: Problems with server stability

[email protected] wrote:
> Hi Stewart,
>
> Sorry for delay in replying. Lots of hats. I will try to answer
your
> questions in order:
> 1. The IDE drives are both on the same channel. I have tried
putting
> them on separate channels both as masters, but this runs into
> problems when you have floppies and CDROM, as the channel is
limited
> to the device with the *lowest* throughput.

Winston,
I have extracted a couple of posts from previous threads
concerning IDE for your reading pleasure:

Post #1:
On Tue, 4 Mar 2003 19:09:46 -0500, Ernie Schroder wrote
> On Tuesday 04 March 2003 15:12, [email protected]
wrote:
> >You should never install IDE drives on the same
> > channel.
>
> Would someone tell me why this is right? I've always worked
under
> the assumption that 2 devices on the same IDE channel would
both
> operate at the speed of the slower drive, thus if I had an UDMA
100
> hard drive and a CD-ROM on the same channel, they would both
run at
> UDMA 33, whereas if I had 2 UDMA hard drives on the same
channel,
>  they would operate at their full speed, assuming my controller
> could handle that. I have always read that mixing hdd's and
cd-roms
> on the same channel was poor practice. 	Who's right? I do see
> something to be said for Stew's way of thinking, though it's
not
> that often that your 2 hdd's write to each other and even when
that
> happens, it seems to me that data can move between 2 UDMA100
drives
> faster than between a UDMA 33 drive and a UDMA 100.

Well, in my limited knowledge let me pass on what I have learned.
I come
from the ole SCSI UNIX days where we would NEVER put an IDE drive
into a UNIX
system.  They all had to be SCSI no matter how much it costed.
The reason at
the time (might not still be valid but I think it is) was that
when the
system made a disk request to a SCSI device it could disconnect
from the
device and let the device handle the request and when the request
was done it
would then interrupt the cpu to tell it that the request was
done.  IN THE
MEAN TIME, being a UNIX, multitasking machine, the cpu was able
to handle a
multitude of actions in the milli seconds the SCSI controller
handled the
request.  WHERE-AS with IDE, the cpu is NOT able to disconnect
from the
controller after the request is put out to the controller until
an answer is
provided from the controller.  That is my understanding.  Read on
for info on
2 IDE drives on the same controller.

So you might say, so what, we are talking about milli seconds
here, well, yes
we are but we are also talking not about a system sitting in
front of a
single individual waiting for him to finish his next sip of
coffee but a
machine that might be a web server, mail server, authentication
server, dhcp
server, and a hundred other types of servers.  Milli seconds
count big time
here.

Anyway, why not 2 drives on a single IDE chain.  Well, all the
info I have
read about RAID (and ALL of my servers implement some level of
RAID) say DO
NOT put 2 drives on a single IDE chain.  Therefor I don't.

One additional note, ALL of my servers use SCSI drives in a RAID
configuration for their main system drives.  I use IDE drives in
a RAID
configuration for the users data storage drives and as backup for
remote
systems.  Why??  Well, IDE drives are BIG (GB) & DIRT CHEAP!!!!
and I don't
need big drives for the system, just for the users data.

Hey, I might be wrong in my explanation.  Please chime in if you
have more
technical info to add.

Thanks.

stew

End of Post#1

Post #2:
Several reasons for SCSI earlier on  -
The main reason for using SCSI in servers - Like Pertec -
Seven drives per disk chain as opposed to IDE's two.
(now up to 15 drives on Wide scsi.)
better performance than Pertec controllers, became cheaper as
well in time.
Controller supported DMA IO to RAM.
SCSI controllers were faster IO bus wise than IDE.
DMA meant that One drive could be transferring while all the
others could
be set to seek to the next CTS to be read/written by the
controller. I think the seek operations need to be started first
but the controller can take the seek completion interrrupt nwhile
the dma continued DMA also freed the cpu to do other things while
the disk controller handled the data transfer.
the cpu was only needed to handle the device interrupts and
schedule the
next tasks on the	controller.

However that advantage has been mostly dead for some time now.
EIDE/UDMA provides
The same two drive limitation as older IDE, yuch!.
Transfer rates comparable to all versions of SCSI at a lower
cost.
(one standard is always ahead for a short time until the other
catches up.
Lower cost than SCSI across the board.
DMA IO with all the advantages.
I am not sure if parallel seek is available.
I am not sure if the Controller has to stay locked to the drive
anymore
since the DMA operation	is usually handled by a separate chipset.
I dont think a parallel seek can be done while the IO operation
is in progress since that requires a switch on the master-slave
unit select control line.  I think the driver would have to start
all the seeks in motion and start the DMA Io on the
first drive to reach the correct position.

I think the real main difference today is that SCSI can handle
far more disk
drives per server than an EIDE based system.

My General Rule -	if you are building a low end server or
workstation without huge disk drive needs or IO demands use
UltraDMA/133 or slower EIDE controllers and 200 GB or smaller
EIDE harddrives.

if you need a server with more disk capacity, use high end Ultra
Scsi disk
controllers	and large capacity scsi disk drives	(Ultra 160's may
be the fastest at this point if memory serves correct.

And if you want really fast disk performance and have oodles of
cash -
FibreChannel 2 at 2 Gbps using dual Fibrechannel switches and
dynamic Multipathing for redundancy - use arrays of Fibrechannel
drives with hardware raid controllers in the array.


  >> WHERE-AS with IDE, the cpu is NOT able to
++> disconnect from the
++> controller after the request is put out to the controller
++> until an answer is
++> provided from the controller.  That is my understanding.
++> Read on for info on
++> 2 IDE drives on the same controller.
++>
++> So you might say, so what, we are talking about milli
++> seconds here, well, yes
++> we are but we are also talking not about a system sitting
++> in front of a
++> single individual waiting for him to finish his next sip of
++> coffee but a
++> machine that might be a web server, mail server,
++> authentication server, dhcp
++> server, and a hundred other types of servers.  Milli
++> seconds count big time
++> here.
++>
++> Anyway, why not 2 drives on a single IDE chain.  Well, all
++> the info I have
++> read about RAID (and ALL of my servers implement some level
++> of RAID) say DO
++> NOT put 2 drives on a single IDE chain.  Therefor I don't.

I think this only applies if you plan to RAID those two drives
together
say in a RAID 1 mirror. That chokes the IDE BUS down doing double
IO's to those drives.

If you do RAID, you mirror Drive 0 on IDE chain 0 to Drive 0 on
IDE chain 1.
If you dump the cdrom drive, mirror drive 1 to drive 1 as above.
You can have three hard drives and a cdrom on your IDE chains as
long as
only the two master IDE drives are involved in a RAID 1 drive to
drive mirror. Raid 5 is totally out of the question.

In  any case, you would be better off with a hardware RAID
controller with
onboard cache.

The same chain to chain Raid 1 mirror rule applies to SCSI buses
for the
same reason.  RAID 5 is possible. striping is possible with SCCI
because of the higher drive numbers and the paraller seek
capability.

++>
++> One additional note, ALL of my servers use SCSI drives in a
RAID
++> configuration for their main system drives.  I use IDE
++> drives in a RAID
++> configuration for the users data storage drives and as
++> backup for remote
++> systems.  Why??  Well, IDE drives are BIG (GB) & DIRT
++> CHEAP!!!! and I don't
++> need big drives for the system, just for the users data.

I agree..........

End of Post#2

Although this is possibly not your problem I would still consider
breaking out the hard drives onto their own controllers.


> 2. On machines 2 and 3 we are running the basic kernel.

Winston,  I thought I remember reading somewhere about a kernel
specifically for large memory machines or maybe it was large file
sizes.  Can't remember and can't put my hands on it now.

Good luck.

stew




>
> Thanks for your interest
>
> Winston
>
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]On Behalf Of Stewart M.
Ives
> Sent: Friday, March 28, 2003 7:14
> To: [email protected]
> Subject: RE: Problems with server stability
>
>
> See questions in-line (a top poster I'm learning not to be):
>
> [email protected] wrote:
>> Hi,
>>
>> I'm new to this list, and I'm hoping you may be able to help
me out.
>>
>> We have 3 generic Intel servers running RH7.2, and 2 of them
have
>> major stability problems. They are as follows:
>> 1. firewall - no problems.
>> This is a small (1Gb memory) machine with 2 software RAID 1'd
IDE
>> drives, performing firewall and DNS services.
>
> Just out of curiosity, how do you have these IDE drives hooked
> up??  Do you have a single drive on a single IDE channel or do
> you have 2 drives on a single IDE channel.  I don't think this
> has any bearing on your problem but I have always read that in
a
> software RAID configuration w IDE drives, we only should put a
> single IDE drive on a single IDE channel.
>
>> 2. Application routing server - constant problems
>> Medium-sized (2Gb memory) machine with 2 software RAID 1'd IDE
>> drives, running Jetty HTTP server serving Java servlets.
>> 3. Database server - intermittent problems
>> Big server (3Gb memory) + Disk Array: 2 onboard and 6 external
SCSI
>> disks, all software RAID 1'd, running Jetty HTTP server and
Oracle
>> 8.1.7.
>
> On #2 & #3 are you running the BIG KERNEL or the basic kernel??
>
>>
>> In addition to the above mentioned software, all machines also
run
>> tripwire intrusion detection software as well.
>>
>> On both machines that have problems, the system either freezes
or
>> crashes just after 4AM, making me think that it may have
something to
>> do with the cron.daily jobs. I found some pages on the Web
from
>> people who had problems with machines crashing when makewhatis
runs,
>> but supposedly the problem was fixed in 7.1. On the database
server I
>> would sometimes get messages saying that the system did not
have
>> enough memory to execute a fork() shortly before the system
froze (it
>> didn't halt; the console merely stopped responding). On the
>> Application server, the system would simply power itself down
(badly;
>> as though someone had simply turned it off at the wall)
shortly
>> after 4AM every 3rd or 4th day.
>>
>> I am completely mystified by the problem as there are no
diagnostics
>> or log messages to indicate that any problem is occurring; the
system
>> simply freezes or shuts down. It does not happen *every* day,
but
>> consistently once or twice a week and most often on Sunday
mornings,
>> when the weekly jobs also run (but *before* they do). After I
set the
>> database server to reboot itself once a week the problem
occurs far
>> less frequently, but it still happens from time to time.
>>
>> Has anyone else run into this problem? I understand that we
are
>> probably unusual in running software RAID, but it is essential
for us
>> to have servers which can be quickly recovered in the event of
a disk
>> crash and hardware RAID cards are expensive (and a single
point of
>> failure).
>>
>> Alternatively, does anyone know of any monitoring tools which
might
>> be of help in uncovering this maddeningly un-reproducable
mystery?
>>
>> Hope you can help me because I'm rapidly losing what hair I
have
>> left! :-)
>>
>> Thanks in advance
>>
>> Winston Gutkowski
>>
>>
>>
>> _______________________________________________
>> enigma-list mailing list
>> [email protected]
>> https://listman.redhat.com/mailman/listinfo/enigma-list
>
> stew
>
> ---
> Outgoing SofTEC USA mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.465 / Virus Database: 263 - Release Date:
3/25/2003
>
>
>
>
> _______________________________________________
> enigma-list mailing list
> [email protected]
> https://listman.redhat.com/mailman/listinfo/enigma-list
>
>
>
> _______________________________________________
> enigma-list mailing list
> [email protected]
> https://listman.redhat.com/mailman/listinfo/enigma-list


---
Outgoing SofTEC USA mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.465 / Virus Database: 263 - Release Date: 3/25/2003