From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 29 13:13:03 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84180106568E for ; Mon, 29 Sep 2008 13:13:03 +0000 (UTC) (envelope-from michael.schuh@gmail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.170]) by mx1.freebsd.org (Postfix) with ESMTP id 4E1148FC29 for ; Mon, 29 Sep 2008 13:13:03 +0000 (UTC) (envelope-from michael.schuh@gmail.com) Received: by wf-out-1314.google.com with SMTP id 24so2010153wfg.7 for ; Mon, 29 Sep 2008 06:13:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type:references; bh=7tCN8rzG0v3jbiNu+6OnxGLDExy0Lcd80BHxwroIP0Y=; b=R6nUc3Sq70gwxtHTIQiFVPn0z/ZnVloj6S9v0RMKEhFt96jFFsYXjWiR5g9LkBw+Bd xoYiEXki4njT++vfHxdsHxHo08UEYLrYlCzkQVuKSM0zvhJa6lwqKL/I5aC0RoWguoXr Qjq/Q1o5pSKqpW1jQXl9S14VQcIVH08KiMa7g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:references; b=yEO94mP6eeWxzRPHK64B4wm1PZlgbbKQ55+clW9pPlfx9fRDrtu+2VUgMrXHCVDeUr Fe3rN+BWppzHw8auL7O0VNw1H8GU/EES6kDL/rLLl2atntE7YJEt4s0efz0a+Am1Al6A le6Khi+dsd3AuD+GIf/RedBDZ6VODWrfqwoqQ= Received: by 10.142.47.6 with SMTP id u6mr2177440wfu.300.1222693982586; Mon, 29 Sep 2008 06:13:02 -0700 (PDT) Received: by 10.142.170.11 with HTTP; Mon, 29 Sep 2008 06:13:02 -0700 (PDT) Message-ID: <1dbad3150809290613j3ebd7226t15918234332fa598@mail.gmail.com> Date: Mon, 29 Sep 2008 15:13:02 +0200 From: "Michael Schuh" To: freebsd-hackers@freebsd.org In-Reply-To: <200809291300.m8TD0G86079925@lurza.secnetix.de> MIME-Version: 1.0 References: <1dbad3150809290136r2af024bdha9672aa0418e6cda@mail.gmail.com> <200809291300.m8TD0G86079925@lurza.secnetix.de> X-Mailman-Approved-At: Mon, 29 Sep 2008 13:50:09 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: experimantal question about md's X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2008 13:13:03 -0000 Hello @all, hello Oliver, thnak you for your reply. No i do not try to solve a real problem. It was hypothetically, an idea, not more not less. I have this written in my first posting. And for me, it is a logical dependency that the ram get paged to the swap i= f there is not enough RAM for all processes and in-memory data. I think my question is answered good enough. Thanks for all. greetings Michael 2008/9/29 Oliver Fromme > Michael Schuh wrote: > > Clearly the Writeprocess of writeing data to an mirror is totally ende= d, > as > > all mirrordevices are written. > > But for the read the kernel uses the faster device......and there it > could > > be an advantage.....i m thinking. > > And yes i think it could be an advantage, if the RAMed mirror is very > fast, > > we have only to wait > > for the first initialization, all the ongoing reads go to the ramdisk, > all > > writes goes to both devices. > > I think it would be completely sufficient to use a normal > device and let the kernel cache the data. This is much > better because the kernel dynamically adapts the cache > size to the workload and memory requirements. > > If you use an unusual asymmetric mirror setupt with a > physical disk and a memory disk (swap-backed), the machine > will have to start paging as soon as the requirements of > your processes grow beyond what's available. This will > be very slow, of course. > > For example (a little bit simplified): Say there's a spike > in web accesses so you get many processes that want to > allocate memory. If you run out of free memory, the kernel > will drop some pages that contain cached data and re-use > them. If the cached data is used later, the kernel will > re-read it from the disk. On the other hand, if you use > a memory disk, you effectively reduce the amount of memory > available by the size of that disk. If a process wants > to allocate memory now, the kernel can't simply drop any > pages used by the memory disk -- it has to write them to > the swap area first. It is obvious that the performance > is worse. > > And of course, the kernel will still try to cache the file > system data (the VFS code doesn't care that the file system > is on a gmirror with one half on a memory disk). So the > cache and the memory disk fight for RAM at the same time. > Basically you would be wasting RAM and losing performance. > > > if i have enough ram in the box, it is possible to say: Hi kernel use > plase > > 8 Gigs of ram for buffering > > the directory abc on the disk directaccesABC ??? i think not. > > The kernel will basically use all available RAM for > caching and buffering. This works especially well for > static web content. There are a few sysctl variables > to influence the behaviour, but it's usually better not > to touch them. > > I get the impression that you're trying to solve a problem > that doesn't exist. If you think you _do_ have a problem, > please provide some evidence, such as output from iostat, > gstat, vmstat and so on. > > Best regards > Oliver > > -- > Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. > Handelsregister: Registergericht Muenchen, HRA 74606, Gesch=E4ftsfuehrun= g: > secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M=FC= n- > chen, HRB 125758, Gesch=E4ftsf=FChrer: Maik Bachmann, Olaf Erb, Ralf Geb= hart > > FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd > > "C++ is to C as Lung Cancer is to Lung." > -- Thomas Funke > --=20 =3D=3D=3D m i c h a e l - s c h u h . n e t =3D=3D=3D Michael Schuh Postfach 10 21 52 66021 Saarbr=FCcken phone: 0681/8319664 mobil: 0177/9738644 @: m i c h a e l . s c h u h @ g m a i l . c o m =3D=3D=3D Ust-ID: DE251072318 =3D=3D=3D