<div dir="ltr">Hello Alex,<div><br></div><div>Thanks for the help.</div><div>I have written a simple perl script that outputs the contents of the metadata of the rock database slots Maybe it will be useful for other squid users.</div><div><b><a href="http://rock_cache_dump.pl">rock_cache_dump.pl</a></b><br></div><div><br></div><div><font face="monospace">#!/usr/bin/perl<br>use strict;<br>use warnings;<br>use Data::Dumper;<br>use Sys::Mmap;<br><br></font></div><div><font face="monospace">my ($file) = @ARGV;<br>die "Usage: $0 <cache_dir>/rock\n" if not $file;<br><br>my @TLVS = ('VOID', 'KEY_URL', 'KEY_SHA', 'KEY_MD5', 'URL', 'STD', 'HITMETERING', 'VALID', 'VARY_HEADERS', 'STD_LFS', 'OBJSIZE', 'STOREURL', 'VARY_ID', 'END');<br><br>open my $fh, '<', $file or die;<br>my %H, $mmap;<br>mmap($mmap, 0, PROT_READ, MAP_SHARED, $fh) or die "Can't mmap: $!";<br><br>my $slots = length($mmap)/0x4000-1;<br>my($slot, $empty_slots, $used_slots, $first_slot, $start_time) = (0, 0, 0, 0, time);<br><br>while($slot<$slots){<br>        my($key, $total_len, $current_len, $version, $first_slot, $next_slot, $meta_ok, $tlvheader_len) = unpack('H32QLLLLCL', substr($mmap, ($slot+1)<<14, 45));<br>        if($first_slot){$used_slots++}else{$empty_slots++}<br>        process_slot($slot,$version, $tlvheader_len) if($next_slot && $meta_ok == 3 && $first_slot == $slot);<br>        $slot++<br>}<br><br></font></div><div><font face="monospace">print Dumper(\%H);<br>print STDERR "File size: \t".int(length($mmap)/1024/1024)." MB\nTotal slots: \t".($empty_slots+$used_slots)."\nEmpty slots: \t$empty_slots\nUsed  slots: \t$used_slots\nUsage: \t\t".int($used_slots*100/($empty_slots+$used_slots))." %\nProcess time:\t".(time-$start_time)." s\n\n";<br><br>sub process_slot{<br>  my($slot, $version, $tlvheader_len) = @_;<br>  $tlvheader_len-=5;<br>  $H{$slot}={VERSION => "".localtime($version)};<br><br>  my $remain=substr($mmap, (($slot+1)<<14)+45, $tlvheader_len);<br><br>  my($type, $len, $value);<br>  while($remain){<br><br>        ($type, $len,$remain) = unpack('cLa*', $remain);<br>        ($value, $remain) = unpack("a$len"."a*", $remain);<br>        $H{$slot}{$TLVS[$type]} = $value;<br>        $H{$slot}{$TLVS[$type]} = unpack("A*", $H{$slot}{$TLVS[$type]}) if($type == 4 || $type == 8); #URL || VARY_HEADERS<br>        $H{$slot}{$TLVS[$type]} = unpack("H*", $H{$slot}{$TLVS[$type]}) if($type == 3 ); #KEY_MD5<br>        $H{$slot}{$TLVS[$type]} = unpack("Q*", $H{$slot}{$TLVS[$type]}) if($type == 10); #OBJSIZE<br>        $H{$slot}{$TLVS[$type]} = parse_STD(unpack("qqqqQSH4", $H{$slot}{$TLVS[$type]})) if($type == 9); #STD_LFS<br>  }<br><br>}<br><br>sub parse_STD{<br>   my($timestamp, $lastref, $expires, $lastmod) = map {"".localtime($_)} @_[0..3];<br>   my($swap_file_sz, $refcount, $flags)  = ($_[4], $_[5], $_[6]);<br>   return {timestamp => $timestamp, lastref => $lastref, expires => $expires, lastmod => $lastmod, swap_file_sz => $swap_file_sz, refcount => $refcount, flags => "0x".$flags};<br>}<br></font></div><div><br></div><div>And maybe you will add it to new squid releases.</div><div><br></div><div>Kind regards,</div><div>       Ankor.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">чт, 6 апр. 2023 г. в 20:35, Alex Rousskov <<a href="mailto:rousskov@measurement-factory.com">rousskov@measurement-factory.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 4/6/23 09:08, Andrey K wrote:<br>
<br>
> Could you tell me if there is a way to view the objects (URLs) and their <br>
> statuses stored in the rock file?<br>
<br>
There is no visualization software for rock db storage. One can <br>
obviously use xxd and similar generic tools to look at raw db bytes, <br>
even in a running Squid instance, but your needs are probably different.<br>
<br>
<br>
> I tried unsuccessfully to find this information using squidclient in <br>
> mgr:menu.<br>
<br>
Cache manager queries are currently ineffective for analyzing individual <br>
rock cache_dir objects because cache manager code relies on the legacy <br>
in-memory worker-specific store index while rock uses shared memory <br>
structures shared among workers.<br>
<br>
<br>
> You gave me a very useful link: <br>
> <a href="https://wiki.squid-cache.org/Features/LargeRockStore" rel="noreferrer" target="_blank">https://wiki.squid-cache.org/Features/LargeRockStore</a> <br>
> Maybe there is a more detailed description of the internal rock data <br>
> structures?<br>
<br>
IIRC, the next level of detail is available in source code only. For <br>
starting points, consider src/fs/rock/RockDbCell.h and the end of <br>
Rock::SwapDir::create() that writes an all-zeroes db file header.<br>
<br>
<br>
HTH,<br>
<br>
Alex.<br>
<br>
<br>
> I could try to write a script that reads the necessary information from <br>
> the cache_dir file.<br>
> <br>
> Kind regards,<br>
>       Ankor.<br>
> <br>
> <br>
> ср, 5 апр. 2023 г. в 16:27, Alex Rousskov <br>
> <<a href="mailto:rousskov@measurement-factory.com" target="_blank">rousskov@measurement-factory.com</a> <br>
> <mailto:<a href="mailto:rousskov@measurement-factory.com" target="_blank">rousskov@measurement-factory.com</a>>>:<br>
> <br>
>     On 4/5/23 06:07, Andrey K wrote:<br>
> <br>
>      > Previously, caching was disabled on our proxy servers. Now we<br>
>     need to<br>
>      > cache some content (files about 10 MB in size).<br>
>      > So we changed the squid.conf:<br>
> <br>
>      > cache_dir ufs /data/squid/cache 32000 16 256 max-size=12000000<br>
>      ><br>
>      > We have 24 workers on each proxy.<br>
> <br>
>     UFS-based cache_dirs are not supported in multi-worker configurations<br>
>     and, in most cases, should not be used in such configurations. The<br>
>     combination will violate basic HTTP caching rules and may crash Squid<br>
>     and/or corrupt responses.<br>
> <br>
> <br>
>      > We saw that some requests were taken from the cache, and some<br>
>     were not.<br>
>      > The documentation says:<br>
>      > "In SMP configurations, cache_dir must not precede the workers<br>
>     option<br>
>      > and should use configuration macros or conditionals to give each<br>
>     worker<br>
>      > interested in disk caching a dedicated cache directory."<br>
> <br>
>     The official documentation quoted above is stale and very misleading in<br>
>     modern Squids. Ignore it. I will try to find the time to post a PR to<br>
>     fix this.<br>
> <br>
> <br>
>      > So we switched to a rock cache_dir:<br>
>      > cache_dir rock /data/squid/cache 32000 max-size=12000000<br>
>      ><br>
>      > Now everything seems to be working fine in the test environment,<br>
>     but I<br>
>      > found limitations on the RockStore<br>
>      > (<a href="https://wiki.squid-cache.org/Features/RockStore" rel="noreferrer" target="_blank">https://wiki.squid-cache.org/Features/RockStore</a><br>
>     <<a href="https://wiki.squid-cache.org/Features/RockStore" rel="noreferrer" target="_blank">https://wiki.squid-cache.org/Features/RockStore</a>>:<br>
>      > "Objects larger than 32,000 bytes cannot be cached when<br>
>     cache_dirs are<br>
>      > shared among workers."<br>
> <br>
>     The Feature/RockStore page is stale and can easily mislead. In general,<br>
>     Feature/Foo wiki pages are often development-focused and get stale with<br>
>     time. They cannot be reliably used as a Squid feature documentation.<br>
> <br>
> <br>
>      > Does this mean that RockStore is not suitable for caching large<br>
>     files?<br>
> <br>
>     No, it does not. Rock storage has evolved since that Feature page was<br>
>     written. You can see the following wiki page discussing evolved rock<br>
>     storage design, but that page probably has some stale info as well:<br>
>     <a href="https://wiki.squid-cache.org/Features/LargeRockStore" rel="noreferrer" target="_blank">https://wiki.squid-cache.org/Features/LargeRockStore</a><br>
>     <<a href="https://wiki.squid-cache.org/Features/LargeRockStore" rel="noreferrer" target="_blank">https://wiki.squid-cache.org/Features/LargeRockStore</a>><br>
> <br>
> <br>
>      > Should I switch back to the UFS and configure 24 cache_dirs<br>
> <br>
>     If everything is "working fine", then you should not. Otherwise, I<br>
>     recommend discussing specific problems before switching to that<br>
>     unsupported and dangerous hack.<br>
> <br>
> <br>
>     HTH,<br>
> <br>
>     Alex.<br>
> <br>
>     _______________________________________________<br>
>     squid-users mailing list<br>
>     <a href="mailto:squid-users@lists.squid-cache.org" target="_blank">squid-users@lists.squid-cache.org</a><br>
>     <mailto:<a href="mailto:squid-users@lists.squid-cache.org" target="_blank">squid-users@lists.squid-cache.org</a>><br>
>     <a href="http://lists.squid-cache.org/listinfo/squid-users" rel="noreferrer" target="_blank">http://lists.squid-cache.org/listinfo/squid-users</a><br>
>     <<a href="http://lists.squid-cache.org/listinfo/squid-users" rel="noreferrer" target="_blank">http://lists.squid-cache.org/listinfo/squid-users</a>><br>
> <br>
<br>
</blockquote></div>