From nobody Fri Oct 27 15:01:03 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SH5TT0qbXz4yLbK for ; Fri, 27 Oct 2023 15:01:17 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.126.123]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4SH5TS5pcWz4ckK for ; Fri, 27 Oct 2023 15:01:16 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Authentication-Results: mx1.freebsd.org; none Received: from itso-dell.gromit23.net (c-174-179-68-208.hsd1.va.comcast.net [174.179.68.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id E1B6875DA2; Fri, 27 Oct 2023 11:01:04 -0400 (EDT) Message-ID: <8a5c1f89eb5842f20e463c7d60538e598da3bc46.camel@gromit.dlib.vt.edu> Subject: Re: periodic daily takes a very long time to run (14-stable) From: Paul Mather To: void , freebsd-stable@freebsd.org Date: Fri, 27 Oct 2023 11:01:03 -0400 In-Reply-To: References: <1122335317.4913.1698407124469@localhost> <794932758.6659.1698413675475@localhost> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.44.4-0ubuntu2 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:1312, ipnet:128.173.0.0/16, country:US] X-Rspamd-Queue-Id: 4SH5TS5pcWz4ckK On Fri, 2023-10-27 at 15:42 +0100, void wrote: > would ktrace and/or truss be useful? something else? The truss -p > output of the > find PID produces massive amounts of output, all like this: >=20 > fstatat(AT_FDCWD,"5e70d5f895ccc92af6a7d5226f818b-81464.o",{ mode=3D-rw- > r--r--=20 > ,inode=3D367004,size=3D10312,blksize=3D10752 },AT_SYMLINK_NOFOLLOW) =3D 0 > (0x0) >=20 > with the filename changing each time >=20 > (later...) >=20 > that file is in ccache!!! >=20 > locate 5e70d5f895ccc92af6a7d5226f818b-81464.o > /var/cache/ccache/f/5/5e70d5f895ccc92af6a7d5226f818b-81464.o >=20 > maybe if I can exclude that dir (and /usr/obj) it'll lessen the > periodic runtime. > But i don't know yet whats calling find(1) when periodic daily runs. > If I can,=20 > I might be able to tell it not to walk certain heirarchies. This doesn't affect the periodic daily run (to my knowledge) but if you are using ccache then it will slow down the periodic weekly run when it executes the /etc/periodic/weekly/310.locate script. I use ccache, too, and my ccache cache file system has millions of files in it. I found no practical use for me to have the weekly locate indexing to include ephemeral ccache files in the locate index. It just slows down the indexing process. You can tinker with the settings in /etc/locate.rc and add your ccache file system/directory to PRUNEPATHS in order to get the /usr/libexec/locate.updatedb indexing script to skip that hierarchy. Cheers, Paul.