Hi, I forgot the name of a command to break/wrap lines for a given text file. Suppose I have a text file, and the text file contains lines more than 80 chars. When I need to wrap all lines, I just need to do comman input.txt > output.txt Regards, Verdi
Hi All & Thorsten K. We're running 12 SuSE NIS slave servers and I'm in the process of upgrading them from 6.4/7.0/7.2 to 8.0. Unfortunately we have intermittent issues where one machine is hammered by client requests until it's battered into submission. When it stops responding the clients all move to the next-fastest responding NIS server and so on .... This is still a problem for the SuSE 8.0 servers. Has anyone looked at a load balancing system for NIS servers or any other solution for clients jumping en-masse to the next server ? Thanks, Damian -- using: SuSE Linux 8.0 9:40am up 69 days, 20:12, 15 users, load average: 0.18, 0.27, 0.26
On Thursday 11 July 2002 03:33, Verdi March wrote:
Hi,
I forgot the name of a command to break/wrap lines for a given text file. Suppose I have a text file, and the text file contains lines more than 80 chars. When I need to wrap all lines, I just need to do comman input.txt > output.txt
I prefer fmt -- JAY VOLLMER JVOLLMER@VISI.COM TEXT REFS DOUBLEPLUSUNGOOD SELFTHINK VERGING CRIMETHINK IGNORE FULLWISE
Hi, you should not post a message with a new subject and topic as replay on this list ;) On Thu, Jul 11, Damian Ohara wrote:
Hi All & Thorsten K.
We're running 12 SuSE NIS slave servers and I'm in the process of upgrading them from 6.4/7.0/7.2 to 8.0.
Unfortunately we have intermittent issues where one machine is hammered by client requests until it's battered into submission. When it stops responding the clients all move to the next-fastest responding NIS server and so on ....
This is still a problem for the SuSE 8.0 servers.
Has anyone looked at a load balancing system for NIS servers or any other solution for clients jumping en-masse to the next server ?
The ypbind load balancing works fine here. It seems your slave servers are in the wrong place of the network. Here, we have always more than one server which is reacheable from the client at the same cost. So if you have 2 slaves in one subnet, every slave has about 50% of the clients, with 3 one 33% (but in worst case our NIS servers are all able to handle the NIS traffic alone). You can try to sort the yp.conf for priority: Use the best server for this client at first and so on. If not all clients have the same yp.conf, they will start searching the fastest server with another server. Thorsten -- Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk@suse.de SuSE Linux AG Deutschherrnstr. 15-19 D-90429 Nuernberg -------------------------------------------------------------------- Key fingerprint = A368 676B 5E1B 3E46 CFCE 2D97 F8FD 4E23 56C6 FB4B
Thanks Thorsten, I'll look at our NIS locations. I'm fairly sure that each client isn't beefy enough to handle all requests on that VLAN if the other servers failed. A good argument for some investment in hardware because at the moment I just get the old stuff that the NT guys can't use. Sorry about the replay business - just being lazy ;-) Damian Thorsten Kukuk wrote:
Hi,
you should not post a message with a new subject and topic as replay on this list ;)
The ypbind load balancing works fine here. It seems your slave servers are in the wrong place of the network. Here, we have always more than one server which is reacheable from the client at the same cost. So if you have 2 slaves in one subnet, every slave has about 50% of the clients, with 3 one 33% (but in worst case our NIS servers are all able to handle the NIS traffic alone). You can try to sort the yp.conf for priority: Use the best server for this client at first and so on. If not all clients have the same yp.conf, they will start searching the fastest server with another server.
Thorsten
-- Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk@suse.de SuSE Linux AG Deutschherrnstr. 15-19 D-90429 Nuernberg
-- Damian O'Hara using: SuSE Linux 8.0 10:41am up 70 days, 21:13, 14 users, load average: 0.16, 0.09, 0.22
participants (4)
-
Damian Ohara -
Jay Vollmer -
Thorsten Kukuk -
Verdi March