In a message dated 1/26/01 3:52:56 PM Eastern Standard Time,
[EMAIL PROTECTED] writes:
I have, but I think these occur when the client doesn't close down the
connection to the server properly. Sometimes I have pserver process
that hangs around for a couple of days, and I (or someone else)
Russ Tremain writes:
At 4:48 PM -0800 1/24/01, Brian Behlendorf wrote:
I recommend mounting /tmp on some sort of memory-based filesystem for
maximum performance - this made a big difference on apache.org.
thanks.. this is the next step; unfortunately, have to upgrade
memory first.
In a message dated 1/24/01 8:46:41 PM Eastern Standard Time,
[EMAIL PROTECTED] writes:
At 4:48 PM -0800 1/24/01, Brian Behlendorf wrote:
On Wed, 24 Jan 2001, Russ Tremain wrote:
So we created a new device that was tuned for performance,
and mounted it on the /tmp used by the pserver.
I
At 8:58 AM -0800 1/25/01, Larry Jones wrote:
Russ Tremain writes:
At 4:48 PM -0800 1/24/01, Brian Behlendorf wrote:
I recommend mounting /tmp on some sort of memory-based filesystem for
maximum performance - this made a big difference on apache.org.
thanks.. this is the next step;
Just to close out this topic, our performance problems
were not related to network performancel The excessive
TCP-level retransmits that I had seen earlier was
a transient problem over our WAN.
The problem was all disk i/o, primarily in the tmp device
that was being used by the pserver.
I
On Wed, 24 Jan 2001, Russ Tremain wrote:
So we created a new device that was tuned for performance,
and mounted it on the /tmp used by the pserver.
I recommend mounting /tmp on some sort of memory-based filesystem for
maximum performance - this made a big difference on apache.org.
At 4:48 PM -0800 1/24/01, Brian Behlendorf wrote:
On Wed, 24 Jan 2001, Russ Tremain wrote:
So we created a new device that was tuned for performance,
and mounted it on the /tmp used by the pserver.
I recommend mounting /tmp on some sort of memory-based filesystem for
maximum performance -
Donald Sharp writes:
No I didn't contradict myself. Perhaps I didn't fully explain...
The kernel routes the socket data to inetd. inetd manages the incoming
and outgoing data from the sockets to different processes stdin and stdout.
That's not how it works. The kernel routes data to and
Hi -
I've reviewed much of the discussion on this list on
CVS server performance, in hopes of finding something related
to the problems we are experiencing our CVS server. So far, I
haven't found anything similar to what we are experiencing.
Apologies if this is a re-hash.
We are running cvs
On Wed, Jan 10, 2001 at 12:56:52PM -0800, Russ Tremain wrote:
Hi -
I've reviewed much of the discussion on this list on
CVS server performance, in hopes of finding something related
to the problems we are experiencing our CVS server. So far, I
haven't found anything similar to what we are
Russ Tremain writes:
We are running cvs 1.10.8 as a pserver on a rather beefy
solaris system. Our repository is fairly large and contains
about 45,000 files. This machine is idle most of the time,
and its only job is to run the CVS server.
There were a bunch of memory leaks in 1.10.8
Donald Sharp writes:
That's not necessarily true, there is not necessarily a need
to do it this way. Sockets form tuples( client ip, client port,
server ip/port )of information that provide information to the kernel
where to route the incoming and outgoing packets. inetd in this
case
At 1:35 PM -0800 1/10/01, Larry Jones wrote:
Russ Tremain writes:
We are running cvs 1.10.8 as a pserver on a rather beefy
solaris system. Our repository is fairly large and contains
about 45,000 files. This machine is idle most of the time,
and its only job is to run the CVS server.
13 matches
Mail list logo
