Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 19 Aug 2014 11:36:58 -0500
From:      "Polyack, Steve" <Steve.Polyack@intermedix.com>
To:        Alan Cox <alc@rice.edu>, "freebsd-stable@freebsd.org" <freebsd-stable@freebsd.org>
Subject:   RE: vmdaemon CPU usage and poor performance in 10.0-RELEASE
Message-ID:  <4D557EC7CC2A544AA7C1A3B9CBA2B3672609CF28E5@exchange03.epbs.com>
In-Reply-To: <53F2790C.20703@rice.edu>
References:  <4D557EC7CC2A544AA7C1A3B9CBA2B36726098846B4@exchange03.epbs.com> <20140813152522.GI9400@home.opsec.eu> <4D557EC7CC2A544AA7C1A3B9CBA2B36726098847AF@exchange03.epbs.com> <CAJUyCcNoTJ3xqkC_Prz3N%2BApEqYy3Mi2gA%2BuDo33dczaTMONrA@mail.gmail.com> <4D557EC7CC2A544AA7C1A3B9CBA2B3672609BBA3C4@exchange03.epbs.com> <53F24E5B.1010809@rice.edu> <4D557EC7CC2A544AA7C1A3B9CBA2B3672609BBA64F@exchange03.epbs.com> <53F2790C.20703@rice.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
> -----Original Message-----
> From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd-
> stable@freebsd.org] On Behalf Of Alan Cox
> Sent: Monday, August 18, 2014 6:07 PM
> To: freebsd-stable@freebsd.org
> Subject: Re: vmdaemon CPU usage and poor performance in 10.0-RELEASE
>=20
> On 08/18/2014 16:29, Polyack, Steve wrote:
> >> -----Original Message-----
> >> From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd-
> >> stable@freebsd.org] On Behalf Of Alan Cox
> >> Sent: Monday, August 18, 2014 3:05 PM
> >> To: freebsd-stable@freebsd.org
> >> Subject: Re: vmdaemon CPU usage and poor performance in 10.0-RELEASE
> >>
> >> On 08/18/2014 13:42, Polyack, Steve wrote:
> >>> Excuse my poorly formatted reply at the moment, but this seems to
> have
> >> fixed our problems.  I'm going to update the bug report with a note.
> >>> Thanks Alan!
> >> You're welcome.  And, thanks for letting me know of the outcome.
> >>
> > Actually, I may have spoken too soon, as it looks like we're seeing
> vmdaemon tying up the system again:
> > root                6  100.0  0.0        0       16  -  DL   Wed04PM   =
   4:37.95 [vmdaemon]
> >
> > Is there anything I can check to help narrow down what may be the
> problem?  KTrace/truss on the "process" doesn't give any information, I
> suppose because it's actually a kernel thread.
>=20
> Can you provide the full output of top?  Is there anything unusual about
> the hardware or software configuration?

This may have just been a fluke (maybe NFS caching the old vm_pageout.c dur=
ing the first source build).  We've rebuilt and are monitoring it now.

The hardware consists of a few Dell PowerEdge R720xd servers with 256GB of =
RAM and array of SSDs (no ZFS).  64GB is dedicated to postgres shared_buffe=
rs right now. FreeBSD 10, PostgreSQL 9.3, Slony-I v2.2.2, and redis-2.8.11 =
are all in use here.  I can't say that anything is unusual about the config=
uration.

> > For the "patch" we simply stole vm_pageout.c from r265945.
> >
> > Steve
> >
> >>>> -----Original Message-----
> >>>> From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd-
> >>>> stable@freebsd.org] On Behalf Of Alan Cox
> >>>> Sent: Wednesday, August 13, 2014 12:14 PM
> >>>> To: Polyack, Steve
> >>>> Cc: Kurt Jaeger; freebsd-stable@freebsd.org
> >>>> Subject: Re: vmdaemon CPU usage and poor performance in 10.0-
> RELEASE
> >>>>
> >>>> On Wed, Aug 13, 2014 at 10:42 AM, Polyack, Steve <
> >>>> Steve.Polyack@intermedix.com> wrote:
> >>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Kurt Jaeger [mailto:lists@opsec.eu]
> >>>>>> Sent: Wednesday, August 13, 2014 11:25 AM
> >>>>>>
> >>>>>> Hi!
> >>>>>>
> >>>>>>> We have a handful of database servers running FreeBSD 10.0-
> RELEASE
> >>>>>>> and PostgreSQL 9.3.4.  The servers have 128GB or 256GB of RAM.
> >>>>>> Are you aware of the recent work on that topic ?
> >>>>>>
> >>>>>> https://www.freebsd.org/news/status/report-2014-04-2014-
> >>>>>> 06.html#PostgreSQL-Performance-Improvements
> >>>>>>
> >>>>>> Maybe kib@ knows more about this ?
> >>>>>>
> >>>>> I've recently read over this and some other posts, but they all see=
m to
> >>>>> center around poor postgres performance.  In our case at least, som=
e
> >> light
> >>>>> to medium usage of postgres generally makes the entire system
> >> unusable.
> >>>>> The patches & documents linked there also all seem to be for -
> CURRENT,
> >>>>> which we aren't running.  We're not too keen on the idea of using
> >>>> CURRENT
> >>>>> in production, either.  We're planning on testing 10-STABLE, but I =
was
> >> just
> >>>>> hoping to gain some insight into what the problem may be and
> whether
> >>>> recent
> >>>>> commits to vmdaemon code in the -STABLE tree may have a positive
> >> effect
> >>>> on
> >>>>> what we've seen.
> >>>>>
> >>>>>
> >>>>  There is a good chance that your problem is fixed by r265945.
> >>>> _______________________________________________
> >>>> freebsd-stable@freebsd.org mailing list
> >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> >>>> To unsubscribe, send any mail to "freebsd-stable-
> >>>> unsubscribe@freebsd.org"
> >>> _______________________________________________
> >>> freebsd-stable@freebsd.org mailing list
> >>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> >>> To unsubscribe, send any mail to "freebsd-stable-
> >> unsubscribe@freebsd.org"
> >> _______________________________________________
> >> freebsd-stable@freebsd.org mailing list
> >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> >> To unsubscribe, send any mail to "freebsd-stable-
> >> unsubscribe@freebsd.org"
> > _______________________________________________
> > freebsd-stable@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> > To unsubscribe, send any mail to "freebsd-stable-
> unsubscribe@freebsd.org"
> >
>=20
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-
> unsubscribe@freebsd.org"



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4D557EC7CC2A544AA7C1A3B9CBA2B3672609CF28E5>