<div dir="ltr"><div class="gmail_default"><div class="gmail_default"><font face="monospace, monospace">Sorry for the delay, I had personal problems for some days.</font></div><div class="gmail_default"><font face="monospace, monospace"><br></font></div><div class="gmail_default"><font face="monospace, monospace">Thank you for include my patch. This will be very usefull.</font></div><div class="gmail_default"><font face="monospace, monospace"><br></font></div><div class="gmail_default"><font face="monospace, monospace">I had read the modifications you have made. This is great. :)</font></div><div class="gmail_default"><font face="monospace, monospace"><br></font></div><div class="gmail_default"><font face="monospace, monospace">For me, I don't need to reset the memory.</font></div><div class="gmail_default"><font face="monospace, monospace"><br></font></div><div class="gmail_default"><font face="monospace, monospace">Because the SHM isn't like stats, even stats_noreset. There is no known in unbound (daemon), that someone is reading the memory (I think).</font></div><div class="gmail_default"><font face="monospace, monospace"><br></font></div><div class="gmail_default"><font face="monospace, monospace">And, SHM will be always the current stats info (total + worker[]). So, if someone reset stats, using 'unbound-control stats', SHM will be reseted to.</font></div><div class="gmail_default"><font face="monospace, monospace"><br></font></div><div class="gmail_default"><font face="monospace, monospace"><br></font></div><div class="gmail_default"><font face="monospace, monospace">We just need this 2, for SHM in read 'client side'</font></div><div class="gmail_default"><font face="monospace, monospace">Both are in /daemon/stats.h</font></div><div class="gmail_default"><font face="monospace, monospace"><br></font></div><div class="gmail_default"><font face="monospace, monospace">struct server_stats</font></div><div class="gmail_default"><font face="monospace, monospace">struct stats_info</font></div><div class="gmail_default"><font face="monospace, monospace"><br></font></div><div class="gmail_default"><font face="monospace, monospace">Maybe, when compiling this file can go to system include files.</font></div><div class="gmail_default"><font face="monospace, monospace">In FreeBSD, the .h file goes to /usr/local/include/</font></div><div class="gmail_default"><font face="monospace, monospace"><br></font></div><div class="gmail_default"><font face="monospace, monospace">Then</font></div><div class="gmail_default"><font face="monospace, monospace">/usr/local/include/unbound_stats.h</font></div><div class="gmail_default"><font face="monospace, monospace"><br></font></div><div class="gmail_default"><font face="monospace, monospace">Or something like this.</font></div><div class="gmail_default"><font face="monospace, monospace"><br></font></div><div class="gmail_default"><font face="monospace, monospace">SHM, is to be used in the same machine, with the same struct.</font></div><div class="gmail_default"><font face="monospace, monospace"><br></font></div><div class="gmail_default"><font face="monospace, monospace">So, when I change unbound, I need to recompile my daemon.</font></div><div class="gmail_default"><font face="monospace, monospace">It's the price. And I pay smiling.</font></div><div class="gmail_default"><font face="monospace, monospace"><br></font></div><div class="gmail_default"><font face="monospace, monospace">Best regards, Softov</font></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-02-23 8:09 GMT-04:00 W.C.A. Wijngaards via Unbound-users <span dir="ltr"><<a href="mailto:unbound-users@unbound.net" target="_blank">unbound-users@unbound.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Luiz,<br>
<br>
Thank you for your patch. I have included it (but not in 1.6.1, but it<br>
is in the code repository for 1.6.2).<br>
<br>
Modified the patch a bit to clean it up and I added unbound-control<br>
stats_shm, that makes unbound-control print out the normal stats output<br>
from it, but using shm to get the information.<br>
<br>
I also added shm-enable and shm-key to unbound.conf. Disabled by default.<br>
<br>
Not sure when to reset the memory, so I didn't. I guess unbound-control<br>
could reset the memory after printing out the results (unless 'noreset')?<br>
<br>
The .h file is harder, unbound.h that gets installed is the obvious<br>
choide, but not sure how to deal with version changes, and different<br>
statistics output...<br>
<br>
Best regards, Wouter<br>
<br>
On 14/02/17 10:57, Luiz Fernando Softov via Unbound-users wrote:<br>
> Hi,<br>
> I don't know if it's relevant, but in January i have sent a message to<br>
> the mailing list<br>
> about this.<br>
><br>
> <a href="http://unbound.net/pipermail/unbound-users/2017-January/004626.html" rel="noreferrer" target="_blank">http://unbound.net/pipermail/<wbr>unbound-users/2017-January/<wbr>004626.html</a><br>
><br>
>> Yes, I would like to get the diff file for that patch. Lower CPU usage<br>
>> is nice, and SHM is an interesting construction. Can you send me the<br>
>> diff; or link to the github pull/push thingy that contains the diff (or<br>
>> the newest diff if you updated it recently)?<br>
> . . .<br>
> I put my changes here. <a href="https://github.com/softov/unbound" rel="noreferrer" target="_blank">https://github.com/softov/<wbr>unbound</a><br>
><br>
> This branch is 1 commit ahead, 12 commits behind NLnetLabs:master.<br>
><br>
> But, if you need, I can make the update.<br>
><br>
>> Depending on how invasive this is, I can put it in the mainline code<br>
>> (optional) or it can be a patch that is available to other users in the<br>
>> contrib directory.<br>
><br>
> As I said before.<br>
><br>
> This make 2 SHM instances and I am using the timer to stats-interval to<br>
> fill the memory.<br>
><br>
> I have some daemons, reading this stats with shmget each second.<br>
> It's been a few weeks since I launched the last release with <br>
> this changes for my clients.<br>
><br>
> I have ~2400 clients running my SO, called FreeBRS - Free BrByte Routing<br>
> System.<br>
> Which is a release based on FreeBSD.<br>
> For those clients, the average of requests are between 50 and 1500 per<br>
> second.<br>
><br>
> I all clientes, the CPU consume is 0%, while using my own daemon,<br>
> who use ssl in a tcp connection like unbound-control.<br>
> The CPU increase ~3% in my daemon and ~2,5% in unbound.<br>
> -- -- -- -- -- -- -- -- -- -- -- --<br>
><br>
>> Although there may be an rc3 because of pkg-config vs autoconf problems,<br>
>> I don't want to introduce features in rc3; so it'd be there for the<br>
>> subsequent release.<br>
><br>
> I thing there is more to do about, like.<br>
> 1 - setting variables in conf (I don't know how)<br>
> * shm-key: number<br>
> * shm-enabled: yes or no<br>
> Maybe<br>
> * shm-interval: number, if 0 or null shm will be filled in the timer<br>
> of stat-interval, like i have made, > 0 will be created a reserved timer<br>
> and I don't know how to interact with the base or how much I can change<br>
> because, you know using threads, this can create problems<br>
><br>
> 2 - reset shared memory - zerofill values<br>
> 3 - A header file.h to be referenced in the binary who is reading this info<br>
> like a file with the struct and etc.<br>
><br>
> For now, I only need the conf options, and I don't know how to make those.<br>
><br>
> It will be my pleasure to help you in some way.<br>
> The Unbound have been helping the community a lot.<br>
> Here in Brazil, its used by about 80% of the ISPs.<br>
><br>
> Thanks for the reply.<br>
> Best regards, Softov<br>
<br>
<br>
</blockquote></div><br></div>