[SLUG] Performance Tuning

2008-09-05 Thread Kyle
Can somebody recommend a reasonably comprehensive but straightforward 
performance tuning article/HowTo/PDF/site I could read pls?


Specifically, I am looking to perf-tune a dual-CPU RAID5 box used as a 
backup server.


--

Kind Regards

Kyle

--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html


Re: [SLUG] Performance Tuning

2008-09-05 Thread Daniel Pittman
Kyle [EMAIL PROTECTED] writes:

 Can somebody recommend a reasonably comprehensive but straightforward
 performance tuning article/HowTo/PDF/site I could read pls?

There isn't one, because...

 Specifically, I am looking to perf-tune a dual-CPU RAID5 box used as a
 backup server.

...what you need to do to tune your system to work effectively as a
backup server is extremely different from, say, tuning to a database
load, to tuning for a compute load, to tuning for anything else.

You have not even given enough information about what you intend to use
it for: 

* what parts of performance are you concerned about?
* what is the backup software?
* how does it get data from the clients?
* where does it spool that data temporarily?
* where does it store it finally?
* what compression, format transformation, etc happens to the data?
* what filesystem are you planning to use, and is that fixed?
* can you use something other than RAID5?
* is it software RAID, hardware, or FakeRAID?
* What sort of dual CPU is it -- two sockets, two cores, or one HT CPU?
* how much memory do you have?

Regards,
Daniel
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html


Re: [SLUG] Performance Tuning

2008-09-05 Thread Tony Sceats
Performance depends specifically on the job at hand, and whilst short on
detail, I would suspect that you want fast file systems and disks optimised
for write speed, but that's probably less than half the story, and I'm
guessing that whatever the rest of the details are, you will be trying to
tune an IO Bound system, so perhaps googling for this will help

anyway, IBM have a pretty good primer for the different types of tuning you
can do that goes reasonably in depth too

http://safari.ibmpressbooks.com/013144753X

On Sat, Sep 6, 2008 at 9:54 AM, Kyle [EMAIL PROTECTED] wrote:

 Can somebody recommend a reasonably comprehensive but straightforward
 performance tuning article/HowTo/PDF/site I could read pls?

 Specifically, I am looking to perf-tune a dual-CPU RAID5 box used as a
 backup server.

 --
 
 Kind Regards

 Kyle

 --
 SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
 Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html


[SLUG] X authorization

2008-09-05 Thread jam
I need to understand X authorization so if anybody can explain to a bear of 
little brain :-)

Once-upon-a-time xhost + would allow anybody to write to your display.
That is no longer true

I have some thin clients (ltsp) running off a server. I actually *really* need 
to write to the display (as opposed to sending a message ie jabber to to user) 
eg
 
This POS is not in operation

I cannot see how xauth would help: The POS daemon program disables 
terminal say, um 17 and puts a message on terminal 17 Disabled etc but 
neither it (The POS daemon) or the user associated with it are running a 
display and may not even be the same server as the LTSP server.

So my basic problem: I need to put a message (say with xmessage) on a 
ThinClient DISPLAY whether-or-not that terminal is logged in, and I can't 
understand the relevant man pages / howtos.

I tried asking the ltsp forums and got nervous evasion. Anybody here know?

Thanks
James
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html


Re: [SLUG] Performance Tuning

2008-09-05 Thread Daniel Pittman
Tony Sceats [EMAIL PROTECTED] writes:

 Performance depends specifically on the job at hand, and whilst short on
 detail, I would suspect that you want fast file systems and disks optimised
 for write speed, 

For backups?  Often you need very fast reads, either to feed a modern
tape streamer at the 30 to 80 MB per second of data it wants[1], or to
be able to perform read and compare operations on existing data for
comparison or pooling purposes (or even just the metadata of millions of
files, really.)

Fast writes are typically the least important part of the backup
system.  They matter, sure, for beating your backup window, but the
actual performance problems often pop up on the read side.  In my
experience, anyhow. :)

Regards,
Daniel

Footnotes: 
[1]  ...and more if you have two or three of these drives attached to a
 single server, which is more common as we have individual machines
 with one to two tapes capacity each -- even for the 800MB native
 LTO4 devices.

-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html


Re: [SLUG] X authorization

2008-09-05 Thread Daniel Pittman
jam [EMAIL PROTECTED] writes:

 I need to understand X authorization so if anybody can explain to a
 bear of little brain :-)

 Once-upon-a-time xhost + would allow anybody to write to your display.
 That is no longer true

What makes you think that?  There have been some changes to X security
over the years, but the fundamental mechanisms are still in place...

So, presumably you have tested this and found that it doesn't work.  How
did you test, and what was the error you encountered?

 I have some thin clients (ltsp) running off a server. I actually
 *really* need to write to the display (as opposed to sending a message
 ie jabber to to user) eg

Are you absolutely, positively sure that you want to allow anyone to
connect to the display?  This is a security nightmare, as anyone allowed
to connect can also capture and forge *all* keyboard and mouse input.

 This POS is not in operation

 I cannot see how xauth would help: The POS daemon program disables 
 terminal say, um 17 and puts a message on terminal 17 Disabled etc but 
 neither it (The POS daemon) or the user associated with it are running a 
 display and may not even be the same server as the LTSP server.

xauth is responsible for managing the (marginally) more secure
authentication mechanisms for X connections -- you don't actually /need/
a display to use it effectively on an X client.

For example, ssh X forwarding uses xauth to allow X software to run on a
remote machine and display relatively securely on the local client.


Now, you do have a problem:

 So my basic problem: I need to put a message (say with xmessage) on a
 ThinClient DISPLAY whether-or-not that terminal is logged in, and I
 can't understand the relevant man pages / howtos.

Getting access while a session is logged in isn't that dire: you need to
arrange for your message source to have access to an X connection to the
appropriate LTSP machine.

That means either host-based trust (xhost +message-source.local) or a
more secure authentication mechanism (xauth with an appropriate key.)

You might want to generate the appropriate MIT-MAGIC-COOKIE-1 data and
arrange for your message source to have access to it, if security is a
concern.


While the login session is active, though, you have a bigger problem:
you will need to do work on your login manager to achieve the same
results.  

For the standard xdm, gdm or kdm system this isn't too dire -- all of
them run scripts, as root, to perform session setup before displaying
the chooser or login panel, and you should be able to use that to
achieve the same result.

For a more custom display manager, which I understand LTSP to use, you
will need to do something more clever.


 I tried asking the ltsp forums and got nervous evasion. Anybody here
 know?

I can't say I am surprised, since this is actually reasonably
challenging in many ways; the security architecture, and the trade-offs
in security make this a difficult approach.


Perhaps you might find another approach effective: can you have the POS
software manage authentication, and be able to display the not in use
banner?

That would make one bit of software responsible for all of this, which
would make it a lot easier to manage.


Alternately, can you SSH to the machine as the logged in user (or root),
then run the message software locally?

Regards,
Daniel
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html


Re: [SLUG] Performance Tuning

2008-09-05 Thread Tony Sceats
Actually I was under the impression that this was a vanilla on-disk backup -
ie, something akin to dumping tgz's onto a server with reliable disks (hence
RAID5)..

I must say though that I am surprised that a tape feeder is faster than
disks to the point of having to maintain a large buffer, but then the last
time I was responsible for any tape system was with a single DDS4 tape
drive.. backup management is the curse of systems admin imho, so I avoid it
at all costs - it's horribly mundane and prone to break at will (but we all
thank the great bit keeper when we need them!)

I was also under the (unreasearched) opinion that incremental change
analysis was performed on the client side, not the backup server side,
although I suppose that backing a large number of similar servers would
result in a lot of the same files being written a lot of times (eg /lib), so
it would be smart to only have one copy of the file and a reference for each
backup that includes this file.. this would certaintly be done on the server
side...

but really the point of the above is that you're almost certaintly right if
you're talking about enterprise backup solutions, and that more to the
point, the precise backup solution/software chosen will drastically change
how you tune the server, which is actually what we were both saying, so it's
a case in point


On Sat, Sep 6, 2008 at 11:03 AM, Daniel Pittman [EMAIL PROTECTED] wrote:

 Tony Sceats [EMAIL PROTECTED] writes:

  Performance depends specifically on the job at hand, and whilst short on
  detail, I would suspect that you want fast file systems and disks
 optimised
  for write speed,

 For backups?  Often you need very fast reads, either to feed a modern
 tape streamer at the 30 to 80 MB per second of data it wants[1], or to
 be able to perform read and compare operations on existing data for
 comparison or pooling purposes (or even just the metadata of millions of
 files, really.)

 Fast writes are typically the least important part of the backup
 system.  They matter, sure, for beating your backup window, but the
 actual performance problems often pop up on the read side.  In my
 experience, anyhow. :)

 Regards,
Daniel

 Footnotes:
 [1]  ...and more if you have two or three of these drives attached to a
 single server, which is more common as we have individual machines
 with one to two tapes capacity each -- even for the 800MB native
 LTO4 devices.

 --
 SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
 Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html


Re: [SLUG] Performance Tuning

2008-09-05 Thread Kyle

Ok,

a couple of responses thus far. Some further info.

The software I can tune myself. I was more looking for Linux specific 
tuning.


* Yes, I was/am concerned about I/O.
* But also ensuring the OS itself (system processes) is not hindering 
anything otherwise.

* The RAID is the storage medium. (Hardware RAID)
* Incremental change analysis is done client side.
* Dual P4's / 1GB RAM
* Filesys is ext3 mounted with 'defaults'


Kind Regards

Kyle


Daniel Pittman wrote:

You have not even given enough information about what you intend to use
it for: 


* what parts of performance are you concerned about?
* what is the backup software?
* how does it get data from the clients?
* where does it spool that data temporarily?
* where does it store it finally?
* what compression, format transformation, etc happens to the data?
* what filesystem are you planning to use, and is that fixed?
* can you use something other than RAID5?
* is it software RAID, hardware, or FakeRAID?
* What sort of dual CPU is it -- two sockets, two cores, or one HT CPU?
* how much memory do you have?


  

--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html


Re: [SLUG] Performance Tuning

2008-09-05 Thread Daniel Pittman
Tony Sceats [EMAIL PROTECTED] writes:

 Actually I was under the impression that this was a vanilla on-disk
 backup - ie, something akin to dumping tgz's onto a server with
 reliable disks (hence RAID5)..

It could be, but that is a pretty uncommon model in my experience.

 I must say though that I am surprised that a tape feeder is faster
 than disks to the point of having to maintain a large buffer, but then
 the last time I was responsible for any tape system was with a single
 DDS4 tape drive..

You poor thing. ;)  Seriously, though, the tape streamers are not faster
than disks in the same class: you can find plenty of enterprise level
U320 / SAS SCSI disk systems that can comfortably supply an LTO4 device.

You start to hit problems when folks want to do this on the cheap, so
back their system with large, slow 7200 or 10K SATA disks on SAS or SATA
controllers; there you really do need to stripe to keep up.

 backup management is the curse of systems admin imho, so I avoid it at
 all costs - it's horribly mundane and prone to break at will (but we
 all thank the great bit keeper when we need them!)

 I was also under the (unreasearched) opinion that incremental change
 analysis was performed on the client side, not the backup server side,
 although I suppose that backing a large number of similar servers would
 result in a lot of the same files being written a lot of times (eg /lib), so
 it would be smart to only have one copy of the file and a reference for each
 backup that includes this file.. this would certaintly be done on the server
 side...

This depends enormously on your backup software; BackupPC and the
various rsync-and-hard-links based backup systems tend to put a lot of
load on the server side.

 but really the point of the above is that you're almost certaintly
 right if you're talking about enterprise backup solutions, and that
 more to the point, the precise backup solution/software chosen will
 drastically change how you tune the server, which is actually what we
 were both saying, so it's a case in point

In my experience there isn't /that/ much difference between enterprise
and home backup strategies, except the order of magnitude: you face
the same sort of performance issues that an LTO4/SAS array user does
with your SATA/DDS[1].

You just face them slower: your tape device needs less MB/second to keep
it streaming rather than scrubbing, but your disks are also slower and
busier, so you have the same sort of dramas with keeping the device fed.

Regards,
Daniel

In my experience, of course, which doesn't mean that /everyone/ is going
to face these same issues.

Footnotes: 
[1]  Well, maybe not with DDS, but with tape hardware that is reasonably
 affordable by home users in this day and age, such as LTO[12], AIT
 and SDLT.

-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html


Re: [SLUG] Performance Tuning

2008-09-05 Thread Daniel Pittman
Kyle [EMAIL PROTECTED] writes:

 The software I can tune myself. I was more looking for Linux specific tuning.

 * Yes, I was/am concerned about I/O.
 * But also ensuring the OS itself (system processes) is not hindering anything
   otherwise.

Unless you are running other processes on the system you can be
reasonably confident that early performance measurement will tell you if
the OS is responsible for problems.

 * The RAID is the storage medium. (Hardware RAID)

You /really/ need to let us know what brand and configuration; 3ware and
Areca have very different performance characteristics; the presence or
absence of a BBU is going to be key, also.

In general, there is a reasonable chance you will find the RAID5
performance of your hardware solution disappointing, and if you can move
to something closer to a RAID10 you will, in general, have better
results.

 * Incremental change analysis is done client side.

Does the data just sit on this system, or is it sent somewhere else
afterwards?  (In other words, is this just a big, reliable hard disk?)

Does this require reading the previous backup, or is it purely date
based?

Do you have a backup window?

 * Dual P4's / 1GB RAM
 * Filesys is ext3 mounted with 'defaults'

You will probably find performance here disappointing.  XFS with a
2.6.24 or more recent kernel will do better, perhaps significantly so.

Otherwise you would want to look for tips on tuning an ext3 filesystem
to be less conservative about performance or, if you can carry the risk,
use ext2, to deliver better write performance.


For a write-only load where the server is, essentially, a big and
reliable hard disk for the backup software then, basically, you don't
have a lot of tuning to do.

The RAID layout and filesystem choices are the only real points to
consider tuning up front -- and, probably, enabling LVM for ease of
future management of volume space.[1]

For 3ware, at least, and probably for other hardware controllers, you
can gain significantly by tuning the queue depth, in line with the
vendors recommendations.


Finally, test, test, test.  Get something as close as possible to your
real load running and identify where the bottleneck is.

[...]

 You have not even given enough information about what you intend to use
 it for: 

 * what parts of performance are you concerned about?
 * what is the backup software?
 * how does it get data from the clients?
 * where does it spool that data temporarily?
 * where does it store it finally?
 * what compression, format transformation, etc happens to the data?
 * what filesystem are you planning to use, and is that fixed?
 * can you use something other than RAID5?
 * is it software RAID, hardware, or FakeRAID?
 * What sort of dual CPU is it -- two sockets, two cores, or one HT CPU?
 * how much memory do you have?

Regards,
Daniel

Footnotes: 
[1]  Depending on your hardware RAID brand you may be able to grow a
 live array, in which case you have more or less the same
 flexibility that LVM would give you.

-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html


Re: [SLUG] X authorization

2008-09-05 Thread jam
On Saturday 06 September 2008 09:44:12 [EMAIL PROTECTED] wrote:
  I need to understand X authorization so if anybody can explain to a
  bear of little brain :-)
 
  Once-upon-a-time xhost + would allow anybody to write to your display.
  That is no longer true

 What makes you think that?  There have been some changes to X security
 over the years, but the fundamental mechanisms are still in place...

saturn is a CentOS 5 machine:

[eeyore] /home/jam [53]% ssh -X saturn xhost +
access control disabled, clients can connect from any host
[eeyore] /home/jam [54]% export DISPLAY=saturn:0  xmessage hello world
Error: Can't open display: saturn:0

 So, presumably you have tested this and found that it doesn't work.  How
 did you test, and what was the error you encountered?

All the stuff that DOES work on a RedHat 9 system tried and does NOT work here

  I have some thin clients (ltsp) running off a server. I actually
  *really* need to write to the display (as opposed to sending a message
  ie jabber to to user) eg

 Are you absolutely, positively sure that you want to allow anyone to
 connect to the display?  This is a security nightmare, as anyone allowed
 to connect can also capture and forge *all* keyboard and mouse input.

This in a typical hungry jacks store: private lan and *nothing* but the POS 
and manager machines present. I'm not adverse to being more clever, I just 
inherited a real not-nice setup and am trying to clean up the mess.
 
  This POS is not in operation
 
  I cannot see how xauth would help: The POS daemon program disables
  terminal say, um 17 and puts a message on terminal 17 Disabled etc but
  neither it (The POS daemon) or the user associated with it are running a
  display and may not even be the same server as the LTSP server.

 xauth is responsible for managing the (marginally) more secure
 authentication mechanisms for X connections -- you don't actually /need/
 a display to use it effectively on an X client.

More RTBM (the bloody manual) :-)
I understood using xauth to get the .Xauthority from one machine and import to 
another

 For example, ssh X forwarding uses xauth to allow X software to run on a
 remote machine and display relatively securely on the local client.

 Now, you do have a problem:
  So my basic problem: I need to put a message (say with xmessage) on a
  ThinClient DISPLAY whether-or-not that terminal is logged in, and I
  can't understand the relevant man pages / howtos.

 Getting access while a session is logged in isn't that dire: you need to
 arrange for your message source to have access to an X connection to the
 appropriate LTSP machine.

 That means either host-based trust (xhost +message-source.local) or a
 more secure authentication mechanism (xauth with an appropriate key.)

 You might want to generate the appropriate MIT-MAGIC-COOKIE-1 data and
 arrange for your message source to have access to it, if security is a
 concern.


 While the login session is active, though, you have a bigger problem:
 you will need to do work on your login manager to achieve the same
 results.  

 For the standard xdm, gdm or kdm system this isn't too dire -- all of
 them run scripts, as root, to perform session setup before displaying
 the chooser or login panel, and you should be able to use that to
 achieve the same result.

 For a more custom display manager, which I understand LTSP to use, you
 will need to do something more clever.

  I tried asking the ltsp forums and got nervous evasion. Anybody here
  know?

 I can't say I am surprised, since this is actually reasonably
 challenging in many ways; the security architecture, and the trade-offs
 in security make this a difficult approach.


 Perhaps you might find another approach effective: can you have the POS
 software manage authentication, and be able to display the not in use
 banner?

 That would make one bit of software responsible for all of this, which
 would make it a lot easier to manage.


 Alternately, can you SSH to the machine as the logged in user (or root),
 then run the message software locally?

Daniel that was most informative and helped me lots. Thank you.

James
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html


Re: [SLUG] X authorization

2008-09-05 Thread Daniel Pittman
jam [EMAIL PROTECTED] writes:
 On Saturday 06 September 2008 09:44:12 [EMAIL PROTECTED] wrote:
  I need to understand X authorization so if anybody can explain to a
  bear of little brain :-)
 
  Once-upon-a-time xhost + would allow anybody to write to your display.
  That is no longer true

 What makes you think that?  There have been some changes to X security
 over the years, but the fundamental mechanisms are still in place...

 saturn is a CentOS 5 machine:

 [eeyore] /home/jam [53]% ssh -X saturn xhost +
 access control disabled, clients can connect from any host
 [eeyore] /home/jam [54]% export DISPLAY=saturn:0  xmessage hello world
 Error: Can't open display: saturn:0

Are you sure that saturn is listening for X connections via TCP, and to
connections from anything but localhost?  Out of the box most modern
systems configure X so that remote TCP isn't possible.

(For example, my current X server does not listen for TCP at all.)

[...]

  I have some thin clients (ltsp) running off a server. I actually
  *really* need to write to the display (as opposed to sending a message
  ie jabber to to user) eg

 Are you absolutely, positively sure that you want to allow anyone to
 connect to the display?  This is a security nightmare, as anyone allowed
 to connect can also capture and forge *all* keyboard and mouse input.

 This in a typical hungry jacks store: private lan and *nothing* but
 the POS and manager machines present. I'm not adverse to being more
 clever, I just inherited a real not-nice setup and am trying to clean
 up the mess.

No worries.  I figure it is better to ask (redundantly) than to have you
discover the problem later. :)

  This POS is not in operation
 
  I cannot see how xauth would help: The POS daemon program disables
  terminal say, um 17 and puts a message on terminal 17 Disabled etc but
  neither it (The POS daemon) or the user associated with it are running a
  display and may not even be the same server as the LTSP server.

 xauth is responsible for managing the (marginally) more secure
 authentication mechanisms for X connections -- you don't actually /need/
 a display to use it effectively on an X client.

 More RTBM (the bloody manual) :-) I understood using xauth to get the
 .Xauthority from one machine and import to another

There isn't that much more to it than that -- the X server has a list of
xauth managed authorities that are allowed to connect, and xauth is a
command line tool to move them around and make them available to the
X client libraries. :)

If you already know how to move them between machines you probably
actually have half the battle solved, and will need very little time
with the manual.

(Also, I sympathise.  The manual for X security related stuff is awful,
 which is a large part of why it took ten years for *any* significant
 use of the SECURITY extension to get out into the wider distributions,
 and then only thanks to OpenBSD via OpenSSH.

 Reading them and trying to work out how this works is not fun.)

[...]

 Daniel that was most informative and helped me lots. Thank you.

No worries.  I hope you can resolve your issue.

One final thought: if you trust the users then an option would be to run
a second X server on an additional virtual terminal on each POS
register.

Have that do *nothing* but display your not in service banner, and
disable server zap, etc, etc.  No window manager, nothing useful, just
the banner.

You could then disable a POS terminal with:

ssh [EMAIL PROTECTED] chvt 8

Substitute 8 for the VT where the second, not in service, banner
software is running.  From there the console can't do much to change
away.

Reversing the process is as simple as the same action, back to the
live VT.


That is, I think, the process I would use to manage this.  It makes life
a *lot* easier for everyone involved, because you no longer have to
worry about security -- you just have your one, single, place to set in
or out of service (active VT), and full control over the banner
environment (so no worries about a session being active or not.)

To further reduce (or, at least, change) complexity, you could also use
a graphical Linux console and a framebuffer image view/display tool
rather than a second X server.

Regards,
Daniel
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html