Re: top shows only part of available physmem
On Thu, Jan 27, 2011 at 01:59:01AM +0100, Bartosz Stec wrote: > W dniu 2011-01-26 19:44, John Baldwin pisze: > >On Wednesday, January 26, 2011 1:04:02 pm Marco van Tol wrote: > >>On Wed, Jan 26, 2011 at 12:35:56PM -0500, John Baldwin wrote: > >>>On Wednesday, January 26, 2011 8:20:28 am Bartosz Stec wrote: > W dniu 2011-01-26 14:06, John Baldwin pisze: > >On Wednesday, January 26, 2011 7:20:34 am Bartosz Stec wrote: > >>Guys, > >> > >>could someone explain me this? > >> > >> # sysctl hw.realmem > >> hw.realmem: 2139029504 > >> > >>top line shows: > >> > >> Mem: 32M Active, 35M Inact, 899M Wired, 8392K Cache, 199M Buf, > >> 58M Free > >> > >>32+35+899+8+199+58 = 1231MB > >> > >>Shouldn't that sum to all available ram? Or maybe I'm reading it wrong? > >>This machine has indeed 2GB of ram on board and showed in BIOS. > >>i386 FreeBSD 8.2-PRERELEASE #16: Mon Jan 17 22:28:53 CET 2011 > >>Cheers. > >First, don't include 'buf' as isn't a separate set of RAM, it is only a > >range > >of the virtual address space in the kernel. It used to be relevant when > >the > >buffer cache was separate from the VM page cache, but now it is mostly > >irrelevant (arguably it should just be dropped from top output). > Thanks for the explanation. So 1231MB - 199MB Buf and we got about 1GB > of memory instead of 2B. > > >However, look at what hw.physmem says (and the realmem and availmem > >lines in > >dmesg). realmem is actually not that useful as it is not a count of the > >amount of memory, but the address of the highest memory page available. > >There > >can be less memory available than that due to "holes" in the address > >space for > >PCI memory BARs, etc. > > > OK, here you go: > # sysctl hw | grep mem > > hw.physmem: 2125893632 > hw.usermem: 1212100608 > hw.realmem: 2139029504 > hw.pci.host_mem_start: 2147483648 > >>>Humm, you should still have 2GB of RAM then. All the memory you set aside > >>>for ARC should be counted in the 'wired' count, so I'm not sure why you see > >>>1GB of RAM rather than 2GB. > >>For what its worth (seems to be the same values top shows), the sysctl's > >>I use to make cacti graphs of memory usage are: (Counts are in pages) > >> > >>vm.stats.vm.v_page_size > >> > >>vm.stats.vm.v_wire_count > >>vm.stats.vm.v_active_count > >>vm.stats.vm.v_inactive_count > >>vm.stats.vm.v_cache_count > >>vm.stats.vm.v_free_count > >> > >>Using the output of those sysctls I allways get a cacti graph which at > >>least very much seems to account for all memory, and has a flat surface > >>in a stacked graph. > >These sysctls are exactly what top uses. There is also a 'v_page_count' > >which is a total count of pages. > > > So here's additional sysctl output from now: > >fbsd# sysctl hw | grep mem >hw.physmem: 2125893632 >hw.usermem: 1392594944 >hw.realmem: 2139029504 >hw.pci.host_mem_start: 2147483648 > >fbsd# sysctl vm.stats.vm >vm.stats.vm.v_kthreadpages: 0 >vm.stats.vm.v_rforkpages: 0 >vm.stats.vm.v_vforkpages: 1422927 >vm.stats.vm.v_forkpages: 4606557 >vm.stats.vm.v_kthreads: 40 >vm.stats.vm.v_rforks: 0 >vm.stats.vm.v_vforks: 9917 >vm.stats.vm.v_forks: 30429 >vm.stats.vm.v_interrupt_free_min: 2 >vm.stats.vm.v_pageout_free_min: 34 >vm.stats.vm.v_cache_max: 27506 >vm.stats.vm.v_cache_min: 13753 >vm.stats.vm.v_cache_count: 20312 >vm.stats.vm.v_inactive_count: 18591 >vm.stats.vm.v_inactive_target: 20629 >vm.stats.vm.v_active_count: 1096 >vm.stats.vm.v_wire_count: 179027 >vm.stats.vm.v_free_count: 6193 >vm.stats.vm.v_free_min: 3260 >vm.stats.vm.v_free_target: 13753 >vm.stats.vm.v_free_reserved: 713 >vm.stats.vm.v_page_count: 509752 >vm.stats.vm.v_page_size: 4096 >vm.stats.vm.v_tfree: 196418851 >vm.stats.vm.v_pfree: 2837177 >vm.stats.vm.v_dfree: 0 >vm.stats.vm.v_tcached: 1305893 >vm.stats.vm.v_pdpages: 3527455 >vm.stats.vm.v_pdwakeups: 187 >vm.stats.vm.v_reactivated: 83786 >vm.stats.vm.v_intrans: 3053 >vm.stats.vm.v_vnodepgsout: 134384 >vm.stats.vm.v_vnodepgsin: 29213 >vm.stats.vm.v_vnodeout: 96249 >vm.stats.vm.v_vnodein: 29213 >vm.stats.vm.v_swappgsout: 19730 >vm.stats.vm.v_swappgsin: 8573 >vm.stats.vm.v_swapout: 5287 >vm.stats.vm.v_swapin: 2975 >vm.stats.vm.v_ozfod: 83338 >vm.stats.vm.v_zfod: 2462557 >vm.stats.vm.v_cow_optim: 330 >vm.stats.vm.v_cow_faults: 1239253 >vm.stats.vm.v_vm_faults: 5898471 > >fbsd# sysctl vm.vmtotal >vm.vmtotal: >System wide totals computed every five seconds: (values in kilobytes) >=== >Processes: (RUNQ: 1 Disk Wait: 0 Page Wait: 0 Sleep: 60) >Virtual Memory: (Total: 4971660K Active
Re: top shows only part of available physmem
W dniu 2011-01-26 19:44, John Baldwin pisze: On Wednesday, January 26, 2011 1:04:02 pm Marco van Tol wrote: On Wed, Jan 26, 2011 at 12:35:56PM -0500, John Baldwin wrote: On Wednesday, January 26, 2011 8:20:28 am Bartosz Stec wrote: W dniu 2011-01-26 14:06, John Baldwin pisze: On Wednesday, January 26, 2011 7:20:34 am Bartosz Stec wrote: Guys, could someone explain me this? # sysctl hw.realmem hw.realmem: 2139029504 top line shows: Mem: 32M Active, 35M Inact, 899M Wired, 8392K Cache, 199M Buf, 58M Free 32+35+899+8+199+58 = 1231MB Shouldn't that sum to all available ram? Or maybe I'm reading it wrong? This machine has indeed 2GB of ram on board and showed in BIOS. i386 FreeBSD 8.2-PRERELEASE #16: Mon Jan 17 22:28:53 CET 2011 Cheers. First, don't include 'buf' as isn't a separate set of RAM, it is only a range of the virtual address space in the kernel. It used to be relevant when the buffer cache was separate from the VM page cache, but now it is mostly irrelevant (arguably it should just be dropped from top output). Thanks for the explanation. So 1231MB - 199MB Buf and we got about 1GB of memory instead of 2B. However, look at what hw.physmem says (and the realmem and availmem lines in dmesg). realmem is actually not that useful as it is not a count of the amount of memory, but the address of the highest memory page available. There can be less memory available than that due to "holes" in the address space for PCI memory BARs, etc. OK, here you go: # sysctl hw | grep mem hw.physmem: 2125893632 hw.usermem: 1212100608 hw.realmem: 2139029504 hw.pci.host_mem_start: 2147483648 Humm, you should still have 2GB of RAM then. All the memory you set aside for ARC should be counted in the 'wired' count, so I'm not sure why you see 1GB of RAM rather than 2GB. For what its worth (seems to be the same values top shows), the sysctl's I use to make cacti graphs of memory usage are: (Counts are in pages) vm.stats.vm.v_page_size vm.stats.vm.v_wire_count vm.stats.vm.v_active_count vm.stats.vm.v_inactive_count vm.stats.vm.v_cache_count vm.stats.vm.v_free_count Using the output of those sysctls I allways get a cacti graph which at least very much seems to account for all memory, and has a flat surface in a stacked graph. These sysctls are exactly what top uses. There is also a 'v_page_count' which is a total count of pages. So here's additional sysctl output from now: fbsd# sysctl hw | grep mem hw.physmem: 2125893632 hw.usermem: 1392594944 hw.realmem: 2139029504 hw.pci.host_mem_start: 2147483648 fbsd# sysctl vm.stats.vm vm.stats.vm.v_kthreadpages: 0 vm.stats.vm.v_rforkpages: 0 vm.stats.vm.v_vforkpages: 1422927 vm.stats.vm.v_forkpages: 4606557 vm.stats.vm.v_kthreads: 40 vm.stats.vm.v_rforks: 0 vm.stats.vm.v_vforks: 9917 vm.stats.vm.v_forks: 30429 vm.stats.vm.v_interrupt_free_min: 2 vm.stats.vm.v_pageout_free_min: 34 vm.stats.vm.v_cache_max: 27506 vm.stats.vm.v_cache_min: 13753 vm.stats.vm.v_cache_count: 20312 vm.stats.vm.v_inactive_count: 18591 vm.stats.vm.v_inactive_target: 20629 vm.stats.vm.v_active_count: 1096 vm.stats.vm.v_wire_count: 179027 vm.stats.vm.v_free_count: 6193 vm.stats.vm.v_free_min: 3260 vm.stats.vm.v_free_target: 13753 vm.stats.vm.v_free_reserved: 713 vm.stats.vm.v_page_count: 509752 vm.stats.vm.v_page_size: 4096 vm.stats.vm.v_tfree: 196418851 vm.stats.vm.v_pfree: 2837177 vm.stats.vm.v_dfree: 0 vm.stats.vm.v_tcached: 1305893 vm.stats.vm.v_pdpages: 3527455 vm.stats.vm.v_pdwakeups: 187 vm.stats.vm.v_reactivated: 83786 vm.stats.vm.v_intrans: 3053 vm.stats.vm.v_vnodepgsout: 134384 vm.stats.vm.v_vnodepgsin: 29213 vm.stats.vm.v_vnodeout: 96249 vm.stats.vm.v_vnodein: 29213 vm.stats.vm.v_swappgsout: 19730 vm.stats.vm.v_swappgsin: 8573 vm.stats.vm.v_swapout: 5287 vm.stats.vm.v_swapin: 2975 vm.stats.vm.v_ozfod: 83338 vm.stats.vm.v_zfod: 2462557 vm.stats.vm.v_cow_optim: 330 vm.stats.vm.v_cow_faults: 1239253 vm.stats.vm.v_vm_faults: 5898471 fbsd# sysctl vm.vmtotal vm.vmtotal: System wide totals computed every five seconds: (values in kilobytes) === Processes: (RUNQ: 1 Disk Wait: 0 Page Wait: 0 Sleep: 60) Virtual Memory: (Total: 4971660K Active: 699312K) Real Memory:(Total: 540776K Active: 29756K) Shared Virtual Memory: (Total: 41148K Active: 19468K) Shared Real Memory: (Total: 4964K Active: 3048K) Free Memory Pages: 105308K /usr/bin/top line: Mem: 4664K Active, 73M Inact, 700M Wired, 79M Cache, 199M Buf, 23M Free Sum (Without Buf): 879,5 MB So what are we looking at? Wrong sysctls/top output or maybe actually FreeBSD doesn't use all available RAM for some reason? Could it be hardware problem? Maybe I should provide some additional data? -- Bartosz Stec _
Re: Living on gmirror: need to reincarnate /etc/rc.early
On Wed, Jan 26, 2011 at 9:17 AM, Alfred Bartsch wrote:
> Doug Barton schrieb:
>> On 01/24/2011 23:20, Eugene Grosbein wrote:
>>> Hi!
>>>
>>> In RELENG_8, gmirror is good enough to keep whole HDD pair withing the
>>> mirror.
>>> Its performance, stability any pretty ease of maintainance allows
>>> to use it widely.
>>>
>>> With wide deployment of gmirror in production I've faced inability
>>> of RELENG_8 to store kernel crashdumps out-of-the-box.
>>> gmirror manual page documents a way to setup FreeBSD so that
>>> it would store crashdumps again but that way involves /etc/rc.early
>>> removed from RELENG_8. I've read about intentions - it was unsafe etc.
>>> But we still need working crashdump support.
>>>
>>> Easiest way is to reincarnate /etc/rc.d/early support making it better
>>> and safer
>>> and it should support gmirror's mechanics for crashdumps out-of-the-box.
>>
>> I'll tell you the same thing I told Kostik way back when I removed it.
>> This is the only thing that anyone has ever suggested a use for in
>> /etc/rc.early, and the "solution" in the man page is a hack. :)
>>
>> If this is something that is necessary to do then I'd prefer to do it
>> properly and add an /etc/rc.d/gmirror that runs in the proper (early)
>> position, and then figure out the proper location in rc.d to handle the
>> second half of the configuration.
>>
>> I'm happy to review patches. :)
>>
>>
>> Doug
>>
> Hi Doug,
> at our site we are using the following scripts in /etc/rc.d to deal with
> gmirror "specials":
>
> First part (/etc/rc.d/gmirror1):
>
> #!/bin/sh
>
> # PROVIDE: gmirror1
> # BEFORE: fsck
> # KEYWORD: nojail
>
> . /etc/rc.subr
>
> name="gmirror1"
> start_cmd="gmirror1_start"
> stop_cmd=":"
>
>
> gmirror1_start()
> {
> echo "gmirror configure -b prefer gm0"
> gmirror configure -b prefer gm0
> }
>
> load_rc_config $name
> run_rc_command "$1"
>
> # run only if provider /dev/mirror/gm0 exists
> test -r /dev/mirror/gm0 || exit 0
> -
> Second part (/etc/rc.d/gmirror2):
>
> #!/bin/sh
>
> # PROVIDE: gmirror2
> # REQUIRE: DAEMON
> # BEFORE: LOGIN
> # KEYWORD: nojail
>
> . /etc/rc.subr
>
> name="gmirror2"
> start_cmd="gmirror2_start"
> stop_cmd=":"
>
> gmirror2_start()
> {
> echo "gmirror configure -b round-robin gm0"
> gmirror configure -b round-robin gm0
> }
>
> load_rc_config $name
> run_rc_command "$1"
>
> # run only if provider /dev/mirror/gm0 exists
> test -r /dev/mirror/gm0 || exit 0
> -
>
> In our environment, the name of the gmirror provider is always
> "mirror/gm0". Variable naming of the provider should be added,
> eventually extracted from "gmirror list" command.
>
> --
> Alfred Bartsch
>
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
>
On a side note without /etc/rc.early how would someone do the following tasks ?
1. On bootup relabel /dev/da2s1d to /dev/label/var where da2s1d is the
var for this box.
2. Convert /usr from gjournal to su+j
Not each task is exactly the same from server to server do to how each
installer / admin decided to layout each disk.
As you may know you cant relabel via glabel label, tunefs -J disable,
gjournal off ..
on a disk that was mounted read / write . The old /etc/rc.early
allowed users to shoot quick scripts in there to fix systems on
a reboot, which is very useful for systems you do not have direct
console access to .
So are we supposed to make a rcng script for each task, is there
another way I am missing ?
--
mark saad | nones...@longcount.org
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: top shows only half of realmem?
On Wednesday, January 26, 2011 1:04:02 pm Marco van Tol wrote: > On Wed, Jan 26, 2011 at 12:35:56PM -0500, John Baldwin wrote: > > On Wednesday, January 26, 2011 8:20:28 am Bartosz Stec wrote: > > > W dniu 2011-01-26 14:06, John Baldwin pisze: > > > > On Wednesday, January 26, 2011 7:20:34 am Bartosz Stec wrote: > > > >> Guys, > > > >> > > > >> could someone explain me this? > > > >> > > > >> # sysctl hw.realmem > > > >> hw.realmem: 2139029504 > > > >> > > > >> top line shows: > > > >> > > > >> Mem: 32M Active, 35M Inact, 899M Wired, 8392K Cache, 199M Buf, > > > >> 58M Free > > > >> > > > >> 32+35+899+8+199+58 = 1231MB > > > >> > > > >> Shouldn't that sum to all available ram? Or maybe I'm reading it wrong? > > > >> This machine has indeed 2GB of ram on board and showed in BIOS. > > > >> i386 FreeBSD 8.2-PRERELEASE #16: Mon Jan 17 22:28:53 CET 2011 > > > >> Cheers. > > > > First, don't include 'buf' as isn't a separate set of RAM, it is only a > > > > range > > > > of the virtual address space in the kernel. It used to be relevant > > > > when the > > > > buffer cache was separate from the VM page cache, but now it is mostly > > > > irrelevant (arguably it should just be dropped from top output). > > > > > > Thanks for the explanation. So 1231MB - 199MB Buf and we got about 1GB > > > of memory instead of 2B. > > > > > > > However, look at what hw.physmem says (and the realmem and availmem > > > > lines in > > > > dmesg). realmem is actually not that useful as it is not a count of the > > > > amount of memory, but the address of the highest memory page available. > > > > There > > > > can be less memory available than that due to "holes" in the address > > > > space for > > > > PCI memory BARs, etc. > > > > > > > OK, here you go: > > > # sysctl hw | grep mem > > > > > > hw.physmem: 2125893632 > > > hw.usermem: 1212100608 > > > hw.realmem: 2139029504 > > > hw.pci.host_mem_start: 2147483648 > > > > Humm, you should still have 2GB of RAM then. All the memory you set aside > > for ARC should be counted in the 'wired' count, so I'm not sure why you see > > 1GB of RAM rather than 2GB. > > For what its worth (seems to be the same values top shows), the sysctl's > I use to make cacti graphs of memory usage are: (Counts are in pages) > > vm.stats.vm.v_page_size > > vm.stats.vm.v_wire_count > vm.stats.vm.v_active_count > vm.stats.vm.v_inactive_count > vm.stats.vm.v_cache_count > vm.stats.vm.v_free_count > > Using the output of those sysctls I allways get a cacti graph which at > least very much seems to account for all memory, and has a flat surface > in a stacked graph. These sysctls are exactly what top uses. There is also a 'v_page_count' which is a total count of pages. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: top shows only half of realmem?
On Wed, Jan 26, 2011 at 12:35:56PM -0500, John Baldwin wrote: > On Wednesday, January 26, 2011 8:20:28 am Bartosz Stec wrote: > > W dniu 2011-01-26 14:06, John Baldwin pisze: > > > On Wednesday, January 26, 2011 7:20:34 am Bartosz Stec wrote: > > >> Guys, > > >> > > >> could someone explain me this? > > >> > > >> # sysctl hw.realmem > > >> hw.realmem: 2139029504 > > >> > > >> top line shows: > > >> > > >> Mem: 32M Active, 35M Inact, 899M Wired, 8392K Cache, 199M Buf, 58M > > >> Free > > >> > > >> 32+35+899+8+199+58 = 1231MB > > >> > > >> Shouldn't that sum to all available ram? Or maybe I'm reading it wrong? > > >> This machine has indeed 2GB of ram on board and showed in BIOS. > > >> i386 FreeBSD 8.2-PRERELEASE #16: Mon Jan 17 22:28:53 CET 2011 > > >> Cheers. > > > First, don't include 'buf' as isn't a separate set of RAM, it is only a > > > range > > > of the virtual address space in the kernel. It used to be relevant when > > > the > > > buffer cache was separate from the VM page cache, but now it is mostly > > > irrelevant (arguably it should just be dropped from top output). > > > > Thanks for the explanation. So 1231MB - 199MB Buf and we got about 1GB > > of memory instead of 2B. > > > > > However, look at what hw.physmem says (and the realmem and availmem lines > > > in > > > dmesg). realmem is actually not that useful as it is not a count of the > > > amount of memory, but the address of the highest memory page available. > > > There > > > can be less memory available than that due to "holes" in the address > > > space for > > > PCI memory BARs, etc. > > > > > OK, here you go: > > # sysctl hw | grep mem > > > > hw.physmem: 2125893632 > > hw.usermem: 1212100608 > > hw.realmem: 2139029504 > > hw.pci.host_mem_start: 2147483648 > > Humm, you should still have 2GB of RAM then. All the memory you set aside > for ARC should be counted in the 'wired' count, so I'm not sure why you see > 1GB of RAM rather than 2GB. For what its worth (seems to be the same values top shows), the sysctl's I use to make cacti graphs of memory usage are: (Counts are in pages) vm.stats.vm.v_page_size vm.stats.vm.v_wire_count vm.stats.vm.v_active_count vm.stats.vm.v_inactive_count vm.stats.vm.v_cache_count vm.stats.vm.v_free_count Using the output of those sysctls I allways get a cacti graph which at least very much seems to account for all memory, and has a flat surface in a stacked graph. HTH, Marco van Tol -- Wanneer je in de afgrond kijkt, kijkt de afgrond ook in jou. - Friedrich Nietzsche ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: top shows only half of realmem?
On Wednesday, January 26, 2011 8:20:28 am Bartosz Stec wrote: > W dniu 2011-01-26 14:06, John Baldwin pisze: > > On Wednesday, January 26, 2011 7:20:34 am Bartosz Stec wrote: > >> Guys, > >> > >> could someone explain me this? > >> > >> # sysctl hw.realmem > >> hw.realmem: 2139029504 > >> > >> top line shows: > >> > >> Mem: 32M Active, 35M Inact, 899M Wired, 8392K Cache, 199M Buf, 58M > >> Free > >> > >> 32+35+899+8+199+58 = 1231MB > >> > >> Shouldn't that sum to all available ram? Or maybe I'm reading it wrong? > >> This machine has indeed 2GB of ram on board and showed in BIOS. > >> i386 FreeBSD 8.2-PRERELEASE #16: Mon Jan 17 22:28:53 CET 2011 > >> Cheers. > > First, don't include 'buf' as isn't a separate set of RAM, it is only a > > range > > of the virtual address space in the kernel. It used to be relevant when the > > buffer cache was separate from the VM page cache, but now it is mostly > > irrelevant (arguably it should just be dropped from top output). > > Thanks for the explanation. So 1231MB - 199MB Buf and we got about 1GB > of memory instead of 2B. > > > However, look at what hw.physmem says (and the realmem and availmem lines in > > dmesg). realmem is actually not that useful as it is not a count of the > > amount of memory, but the address of the highest memory page available. > > There > > can be less memory available than that due to "holes" in the address space > > for > > PCI memory BARs, etc. > > > OK, here you go: > # sysctl hw | grep mem > > hw.physmem: 2125893632 > hw.usermem: 1212100608 > hw.realmem: 2139029504 > hw.pci.host_mem_start: 2147483648 Humm, you should still have 2GB of RAM then. All the memory you set aside for ARC should be counted in the 'wired' count, so I'm not sure why you see 1GB of RAM rather than 2GB. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Living on gmirror: need to reincarnate /etc/rc.early
Doug Barton schrieb:
> On 01/24/2011 23:20, Eugene Grosbein wrote:
>> Hi!
>>
>> In RELENG_8, gmirror is good enough to keep whole HDD pair withing the
>> mirror.
>> Its performance, stability any pretty ease of maintainance allows
>> to use it widely.
>>
>> With wide deployment of gmirror in production I've faced inability
>> of RELENG_8 to store kernel crashdumps out-of-the-box.
>> gmirror manual page documents a way to setup FreeBSD so that
>> it would store crashdumps again but that way involves /etc/rc.early
>> removed from RELENG_8. I've read about intentions - it was unsafe etc.
>> But we still need working crashdump support.
>>
>> Easiest way is to reincarnate /etc/rc.d/early support making it better
>> and safer
>> and it should support gmirror's mechanics for crashdumps out-of-the-box.
>
> I'll tell you the same thing I told Kostik way back when I removed it.
> This is the only thing that anyone has ever suggested a use for in
> /etc/rc.early, and the "solution" in the man page is a hack. :)
>
> If this is something that is necessary to do then I'd prefer to do it
> properly and add an /etc/rc.d/gmirror that runs in the proper (early)
> position, and then figure out the proper location in rc.d to handle the
> second half of the configuration.
>
> I'm happy to review patches. :)
>
>
> Doug
>
Hi Doug,
at our site we are using the following scripts in /etc/rc.d to deal with
gmirror "specials":
First part (/etc/rc.d/gmirror1):
#!/bin/sh
# PROVIDE: gmirror1
# BEFORE: fsck
# KEYWORD: nojail
. /etc/rc.subr
name="gmirror1"
start_cmd="gmirror1_start"
stop_cmd=":"
gmirror1_start()
{
echo "gmirror configure -b prefer gm0"
gmirror configure -b prefer gm0
}
load_rc_config $name
run_rc_command "$1"
# run only if provider /dev/mirror/gm0 exists
test -r /dev/mirror/gm0 || exit 0
-
Second part (/etc/rc.d/gmirror2):
#!/bin/sh
# PROVIDE: gmirror2
# REQUIRE: DAEMON
# BEFORE: LOGIN
# KEYWORD: nojail
. /etc/rc.subr
name="gmirror2"
start_cmd="gmirror2_start"
stop_cmd=":"
gmirror2_start()
{
echo "gmirror configure -b round-robin gm0"
gmirror configure -b round-robin gm0
}
load_rc_config $name
run_rc_command "$1"
# run only if provider /dev/mirror/gm0 exists
test -r /dev/mirror/gm0 || exit 0
-
In our environment, the name of the gmirror provider is always
"mirror/gm0". Variable naming of the provider should be added,
eventually extracted from "gmirror list" command.
--
Alfred Bartsch
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: top shows only half of realmem?
W dniu 2011-01-26 14:06, John Baldwin pisze: On Wednesday, January 26, 2011 7:20:34 am Bartosz Stec wrote: Guys, could someone explain me this? # sysctl hw.realmem hw.realmem: 2139029504 top line shows: Mem: 32M Active, 35M Inact, 899M Wired, 8392K Cache, 199M Buf, 58M Free 32+35+899+8+199+58 = 1231MB Shouldn't that sum to all available ram? Or maybe I'm reading it wrong? This machine has indeed 2GB of ram on board and showed in BIOS. i386 FreeBSD 8.2-PRERELEASE #16: Mon Jan 17 22:28:53 CET 2011 Cheers. First, don't include 'buf' as isn't a separate set of RAM, it is only a range of the virtual address space in the kernel. It used to be relevant when the buffer cache was separate from the VM page cache, but now it is mostly irrelevant (arguably it should just be dropped from top output). Thanks for the explanation. So 1231MB - 199MB Buf and we got about 1GB of memory instead of 2B. However, look at what hw.physmem says (and the realmem and availmem lines in dmesg). realmem is actually not that useful as it is not a count of the amount of memory, but the address of the highest memory page available. There can be less memory available than that due to "holes" in the address space for PCI memory BARs, etc. OK, here you go: # sysctl hw | grep mem hw.physmem: 2125893632 hw.usermem: 1212100608 hw.realmem: 2139029504 hw.pci.host_mem_start: 2147483648 And here's the part of /boot/loader.conf for ZFS tuning which may (or probably may not) connected to this issue: vm.kmem_size="1536M" vm.kmem_size_max="1536M" vfs.zfs.arc_max="1280M" -- Bartosz Stec ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: top shows only half of realmem?
On Wednesday, January 26, 2011 7:20:34 am Bartosz Stec wrote: > Guys, > > could someone explain me this? > > # sysctl hw.realmem > hw.realmem: 2139029504 > > top line shows: > > Mem: 32M Active, 35M Inact, 899M Wired, 8392K Cache, 199M Buf, 58M Free > > 32+35+899+8+199+58 = 1231MB > > Shouldn't that sum to all available ram? Or maybe I'm reading it wrong? > This machine has indeed 2GB of ram on board and showed in BIOS. > i386 FreeBSD 8.2-PRERELEASE #16: Mon Jan 17 22:28:53 CET 2011 > Cheers. First, don't include 'buf' as isn't a separate set of RAM, it is only a range of the virtual address space in the kernel. It used to be relevant when the buffer cache was separate from the VM page cache, but now it is mostly irrelevant (arguably it should just be dropped from top output). However, look at what hw.physmem says (and the realmem and availmem lines in dmesg). realmem is actually not that useful as it is not a count of the amount of memory, but the address of the highest memory page available. There can be less memory available than that due to "holes" in the address space for PCI memory BARs, etc. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
top shows only half of realmem?
Guys, could someone explain me this? # sysctl hw.realmem hw.realmem: 2139029504 top line shows: Mem: 32M Active, 35M Inact, 899M Wired, 8392K Cache, 199M Buf, 58M Free 32+35+899+8+199+58 = 1231MB Shouldn't that sum to all available ram? Or maybe I'm reading it wrong? This machine has indeed 2GB of ram on board and showed in BIOS. i386 FreeBSD 8.2-PRERELEASE #16: Mon Jan 17 22:28:53 CET 2011 Cheers. -- Bartosz Stec ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
