[p4] Re: How can I tell which machine a p4d process is talking to?

rmg at foxcove.com rmg at foxcove.com
Tue Dec 18 12:51:44 PST 2001


Hello all. This thread prompts me to point a few of scripts
along these lines that might be useful to some people. These are
currently only going to work on Unix servers, but if some enterprising soul
wants Windows, have at it!

On my lunch hour,

  - rmg

=== p4://public.perforce.com//guest/richard_geiger/utils/p4wd

  p4wd combines information from a Perforce server host's process
  list and the perforce server log file, and prints a list of current
  perforce processes. Here's an example:
  
  | rmg /p4wd -p4d_log /u/p4/logs.p4netapp/p4d -p4d_pid 24099 -tailn 200000
  |    97 2001/10/23 12:23:08   doucette doucette:raiders:50376 10.56.10.100 'user-flush @135496'
  |  5284 2001/10/23 11:16:09    ericcxu yadav:main 10.56.10.118 'user-diff prod/netcache/server/admin
  |  6535 2001/10/23 12:18:47   rtpbuild rtpbuild:main:135505 10.60.132.58 'user-flush @135501'
  |  6881 2001/10/23 12:23:28   renglish daemon:main 10.56.10.43 'user-sync -n'
  | 15211 15211  24099 p4d                  Mon Oct 22 16:16:23 2001 368K     0:00.01 /u/p
  | 18120 2001/10/23 12:23:32      grier grier:test 10.97.1.25 'user-sync'
  | 18385 2001/10/23 12:23:29   doucette doucette:raiders:56741 10.56.10.47 'user-flush //doucette:raiders:56741/.
  | 20971 2001/10/23 12:23:31    kiyoshi kiyoshi:ontap:ncsr 172.29.19.40 'user-sync'
  | 24099*24099      1 p4d                  Thu Oct 11 16:23:00 2001 272K    17:44.77 /u/p
  
        (^ indicates that this is the parent p4d process)
  
  | 26385 2001/10/23 00:28:59    sunitha sunitha:parityflip_main 10.56.10.118 'user-submit'
  | 26763 2001/10/23 12:19:55     jscott jscott:main:bug57014 10.60.132.16 'user-flush @135485'
  

=== p4://public.perforce.com//guest/richard_geiger/utils/p4mon

    Note: requires p4d 2001.1 or newer

  p4mon is a simple script for looking at a p4d log file (produced
  with "p4d -L <logfile> -v server=2") to produce a listing showing the
  completion times for commands logged therein. This can be useful for
  proactively monitoring the performance seen by users of a Perforce
  server, from the server host. Call your frustrated users before they
  call you! :-)
  
  Here's a sample of the output:
  
     2001/10/23-14:02:33    1 27032 kostadis at kostadis:h1 10.56.10.184 'user-diff -dcw'
     2001/10/23-14:02:14   34  8239 archana at archana:main 10.56.10.106 'user-sync'
     2001/10/23-14:02:47    1 31358 archana at archana:main 10.56.10.106 'user-client -o'
     2001/10/23-14:02:49    1 26775 srikvln at srikvln:skywalker 10.34.10.93 'user-client -o srikvln:skywalke
     2001/10/23-14:02:49    2 30243 bolinger at bolinger:dafsu 10.97.101.97 'user-changes -m 1 ./...'


=== Finally, p4://public.perforce.com//guest/richard_geiger/utils/p4watch/...

    Note: requires the "p4wd" script (see above). Also, setting this up
    is a more elaborate project than the two scripts above, but it can
    be very useful when you do need it!:

  "p4watch" is a tool for tracking down Perforce performance problems,
  when you suspect that something is periodically causing Perforce
  commands which _should_ be quick to execute to get "the slows".
  
  It works by periodically running a (nominally) short-running "p4"
  command, ("p4 describe 1", by default), and watching for the command
  to complete.  If the command has not completed given timeout duration,
  then a "p4wd" is done, in order to log system state.
  
  After "p4wd" has been run, it will also be run again after the
  original "p4" probe command finally completes. (This makes it easy to
  look for other p4d activity which was active at the time the probe
  command timed out, but which is gone after the probe command finally
  completed; these are sometimes good suspects for what caused the
  slowness.
  



More information about the perforce-user mailing list