Date: Mon, 29 Sep 2008 15:13:02 +0200 From: "Michael Schuh" <michael.schuh@gmail.com> To: freebsd-hackers@freebsd.org Subject: Re: experimantal question about md's Message-ID: <1dbad3150809290613j3ebd7226t15918234332fa598@mail.gmail.com> In-Reply-To: <200809291300.m8TD0G86079925@lurza.secnetix.de> References: <1dbad3150809290136r2af024bdha9672aa0418e6cda@mail.gmail.com> <200809291300.m8TD0G86079925@lurza.secnetix.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <olli@lurza.secnetix.de> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1dbad3150809290613j3ebd7226t15918234332fa598>