On Wed, 2006-08-30 at 16:28 -0700, Michael Thomas wrote: > Paul Howarth wrote: > > Anybody have squid working well with mock? > > > > I followed the guide on the wiki (Extras/MockTricks) and have the > > following non-default config options: > > > > cache_swap_low 95 > > cache_swap_high 98 > > maximum_object_size 150000 KB > > maximum_object_size_in_memory 8 MB > > cache_replacement_policy heap LFUDA > > memory_replacement_policy heap LFUDA > > cache_dir ufs /var/spool/squid 4400 16 256 > > acl localnet src 192.168.2.0/24 > > http_access allow localnet > > memory_pools_limit 64 MB > > > > /var/spool/squid is a separate 5G partition but squid seems very > > reluctant to fill it. After several mock builds, it's using only a small > > percentage of the available space: > > > > /dev/mapper/VgBuildSys-squid > > 5160576 489928 4408504 11% /var/spool/squid > > > > The store.log indicates that it's not saving much at all (most RPM > > packages are RELEASE-d, and only the repodata XML files appear to be > > being stored). > > > > Any suggestions as to why this might be, and/or how to debug it? > > Are you sure the RELEASE lines correspond to the actual rpm files and > not the rpm headers? Check for a HTTP status code of 200 for the actual > rpm files, vs. a status code of 206 (partial content) for the rpm > headers. The squid configuration on this page does not cache partial > downloads (will squid even do that?) and will RELEASE them immediately: > > Partial download (rpm header) not stored: > 1156979634.763 RELEASE -1 FFFFFFFF 831BB6E09AECB2516F9279A7271237F9 206 > 1156979626 -1 -1 application/x-rpm 26711/26711 GET > http://newmirror.linux.duke.edu/pub/fedora/linux/core/updates/5/i386/selinux-policy-targeted-2.3.7-2.fc5.noarch.rpm > > Full rpm stored: > 1156979716.933 SWAPOUT 00 00000076 E8B3B83D4E58A2EA421A5B88B72B8C8C 200 > 1156979642 1156785034 -1 application/x-rpm 532860/532860 GET > http://newmirror.linux.duke.edu/pub/fedora/linux/core/updates/5/i386/selinux-policy-targeted-2.3.7-2.fc5.noarch.rpm The only SWAPOUT entries I was getting were for the repo metadata, no rpms. > You might be able to use squidclient to tell you directly if something > is in the cache, but I haven't found decent docuementation for this tool > yet. Instead you can use it to download individual packages and look in > access.log for the TCP_HIT vs. TCP_MISS messages, where TCP_HIT > indicates that a cached object is returned and TCP_MISS indicates that > the object was not cached: It was the absence of TCP_HIT entries in the access.log that alerted me to the problem. I think I've found the problem now. I switched to a different mirror and it appears to be working now. If anyone would like to investigate further, the mirror I had problems with was: http://www.mirrorservice.org/sites/download.fedora.redhat.com/pub/fedora/linux/core/development/i386/os/ http://www.mirrorservice.org/sites/download.fedora.redhat.com/pub/fedora/linux/extras/development/i386/ http://www.mirrorservice.org/sites/download.fedora.redhat.com/pub/fedora/linux/core/development/x86_64/os/ http://www.mirrorservice.org/sites/download.fedora.redhat.com/pub/fedora/linux/extras/development/x86_64/ Paul. -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
