Summary: Question concerning namei cache

From: Brewer, Edward \(NIH/OD\) (BREWERE@OD.NIH.GOV)
Date: Fri Apr 11 2003 - 10:05:02 EDT


Admins,

I got one repsonse.

From: Alan Rollow - Dr. File System's Home for Wayward Inodes.
[alan@desdra.cxo.cpqcorp.net]

        I think the algorithm I used was developed long before
        anybody had thought to write one down in a manual...

        Recent versions of the Monitor kit have "The Long Awaited
        Monitor User's Guide". It is probably a Postscript file.
        It may document the algorithm I used, though you can also
        check the code directly.

        The most likely cause is that the algorithm I used, is
        different than the one recommended by the Tuning guide.
        I'll try to check it someday and update Monitor.

I called HP and they told me it was best to use
/usr/lbin/nchstats
which is the program used in sys_check.

It placed the value at 86%

I also asked about using 8192 for maxusers. There would only be a problem
if I didn't have the memory to support the sizes of tables it would create.
As for the calculation of ncs_goodhits/ncs_badtimehits, this was too high so
I am going to increase the value of the namei_cache_valid_time attribute and
the vnode_age attribute.

Thanks,
Lee Brewer

> -----Original Message-----
> From: Brewer, Edward (NIH/OD)
> Sent: Thursday, April 10, 2003 3:02 PM
> To: 'Tru64-Unix-Managers (E-mail)
> Subject: Followup question for: Question concerning namei cache
>
> Admins,
>
> As a followup I checked on the maxusers value, last year we set this value
> to 8192. I verified this value with sysconfig -q proc.
>
> I have noticed that there are warnings about not setting it above 2048 or
> 4096.... Did we cross into the danger zone?
> Also here are the values of the proc and vfs subsections
>
> proc:
> max_proc_per_user = 1024
> max_threads_per_user = 4096
> per_proc_stack_size = 33554432
> max_per_proc_stack_size = 536870912
> per_proc_data_size = 17179869184
> max_per_proc_data_size = 17179869184
> max_per_proc_address_space = 17179869184
> per_proc_address_space = 17179869184
> executable_stack = 0
> autonice = 0
> autonice_time = 600
> autonice_penalty = 4
> open_max_soft = 4096
> open_max_hard = 4096
> ncallout_alloc_size = 8192
> round_robin_switch_rate = 0
> sched_min_idle = 0
> give_boost = 1
> maxusers = 8192
> num_wait_queues = 8192
> num_timeout_hash_queues = 8192
> enhanced_core_name = 0
> enhanced_core_max_versions = 16
> exec_disable_arg_limit = 0
> dump_cores = 1
> dump_setugid_cores = 0
>
> vfs:
> name_cache_hash_size = 4096
> buffer_hash_size = 2048
> special_vnode_alias_tbl_size = 64
> bufcache = 3
> bufpages = 62822
> path_num_max = 64
> sys_v_mode = 0
> ucred_max = 256
> nvnode = 82068
> max_vnodes = 1209526
> min_free_vnodes = 82068
> vnode_age = 120
> namei_cache_valid_time = 1200
> max_free_file_structures = 0
> max_ufs_mounts = 1000
> max_nfs_mounts = 0
> vnode_deallocation_enable = 1
> pipe_maxbuf_size = 262144
> pipe_databuf_size = 8192
> pipe_max_bytes_all_pipes = 134217728
> noadd_exec_access = 0
> fifo_do_adaptive = 0
> nlock_record = 10000
> smoothsync_age = 30
> io_throttle_static = 0
> io_throttle_shift = 1
> io_throttle_maxmzthruput = 1
> revoke_tty_only = 1
> strict_posix_osync = 0
> pad_dirent = 0
> freezefs_default_timeout = 60
> follow_mkdir_symlinks = 0
>
> TIA,
> Lee Brewer
>
> -----Original Message-----
> From: Brewer, Edward (NIH/OD)
> Sent: Thursday, April 10, 2003 2:28 PM
> To: 'Tru64-Unix-Managers (E-mail)
> Subject: Question concerning namei cache
>
> Admins,
>
> System is a GS160 Wildfire (8 processors) Tru64 5.1a patch kit 3
>
> Currently I have been using monitor to provide me with a value for the
> buffering to the namei cache. I decided to follow the procedures in the
> System Configuration and Tuning for Tru64 5.1a. section 9.1.1 to verify.
> Following the formula I get the namei buffer at a different value than
> monitor.
>
> With monitor it is listed as 87%, by hand I get 77% (which I performed
> twice to be sure). I also did the calculation of
> ncs_goodhits/ncs_badtimehits which should be less than .1 percent...mine
> was 3.8 %. From these indications it looks like I need to do some
> exploring and tuning, What do you think?
>
> Raw Data
>
> ncs_goodhits = 76524644
> ncs_neghits = 6275430
> ncs_badhits = 202144
> ncs_falsehits = 95562
> ncs_miss = 23986482
> ncs_long = 895689
> ncs_badtimehits = 2959832
> ncs_collisions = 25643
> ncs_unequaldups = 23927
> ncs_newentry = 25093548
> ncs_newnegentry = 87703
> ncs_gnn_hit = 6204899
> ncs_gnn_miss = 5594
> ncs_gnn_badhits = 0
> ncs_gnn_collision = 32524
> ncs_pad = {
> [0] 0
>
>
> Lee Brewer



This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:49:15 EDT