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 1.
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 w
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
> c
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 se
On Wed, Jan 10, 2001 at 05:07:33PM -0500, Larry Jones wrote:
> 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
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 a
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 found
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 performan
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 f
On Thu, 25 Jan 2001, Larry Jones wrote:
> A good alternative to the memory based filesystem is a disk based
> filesystem that supports soft updates (even better than a virtual memory
> based filesystem, not quite as good as a physical memory based
> filesystem but a much more efficient use of reso
Brian Behlendorf writes:
>
> In terms of speed, a soft-updates file system is much faster than a
> regular one, but not faster than memory-based.
It depends on what you're doing. If you're creating and deleting a
bunch of small files, soft-updates will probably outperform memory-based
because i
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.
>
>
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
Russ Tremain 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)
> kills these off by hand with kill -9. This will leave the ser
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)
17 matches
Mail list logo
