[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [K12OSN] OT: Build a server challange :-)

Jim Kronebusch wrote:

I have to say I really wanted to run a massive /home server and a separate LDAP then
have all servers talk on a separate gigabit backbone LAN.  But the speed thing stopped
me.  When I did my testing this was all on a Gig LAN and non-production servers.  I
first had my standalone server, then added LDAP and /home at the same time.  When I saw
the speed issues I dropped /home and just used LDAP.  The speed problem was cut in about
half.  Then I added /home back on and dropped LDAP for local accounts, speed stayed
about the same.  So it seemed that each service contributed to about half of my couple
second lag compared to standalone.

That makes even less sense. LDAP should only be checked during login and should take much time if your directory fits in ram on the LDAP server. It might be worth doing a wireshark capture on the authentication conversation to see if there are big delays. You should also be able to run nscd to cache the results but I'm not sure why that would be needed and it can cause some mysterious issues when things change.

Right now I have the same server serving a small
test lab of 15 clients with /home NFS mounted from my current file server but using
local unix accounts.  I just want to get rid of that 1-2 second lag that I didn't have
when everything was local.

As far as async goes, I had just used the default /home export config from a k12ltsp
server.  Here is the export line in my current file server:


Now I know that exporting to the entire 10.6.x.x network isn't exactly secure, but I
don't really care at this point.  However I see that the export uses sync instead of
async.  I also see that the /var/opt/ltsp/swapfiles are exported with async and
/opt/ltsp/i386 is exported with sync.  What is the difference?  If exporting with async
is faster why isn't k12ltsp set this way by default?

sync means that all writes are flushed to disk before being acknowledged as complete to the client (something that doesn't happen on your local disks...). It is more reliable, but at a big cost in speed and I've never seen much reason to ask a remote filesystem to be more reliable than the local one - and the NFS server is likely to have a better UPS in many settings. I didn't think this should affect startup time much, but perhaps the window managers rewrite some of their setup files. Try some different block sizes in the mount options too, to see if that makes a difference.

  Les Mikesell
    les futuresource com

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]