Roxen.git / server / translations / eng / roxen_config.xml

version» Context lines:

Roxen.git/server/translations/eng/roxen_config.xml:246:   <tr><td>$utc-date</td>    <td>UTC date formatted like '<code>2001-01-17</code>'.</td></tr>      <tr><td>$utc-time</td>    <td>UTC time formatted like '<code>13:00:00</code>'.</td></tr>   <tr><td>$bin-date</td>    <td>Unix time as a 32 bit integer in network byte order.</td></tr>   <tr><td>$resource</td>    <td>Resource identifier. For events, this is either a path to a    file (if it begins with '<code>/</code>') or some other kind of -  resource indentifier (otherwise).</td></tr> +  resource identifier (otherwise). It is '-' for events that doesn't +  act on any specific resource.</td></tr>   <tr><td>$server-uptime</td>    <td>Server uptime in seconds.</td></tr>   <tr><td>$server-cputime</td>    <td>Server cpu (user+system) time in milliseconds.</td></tr>   <tr><td>$server-usertime</td>    <td>Server cpu user time in milliseconds.</td></tr>   <tr><td>$server-systime</td>    <td>Server cpu system time in milliseconds.</td></tr>   </tbody></table>   
Roxen.git/server/translations/eng/roxen_config.xml:393:   <tr><td>$protcache-cost</td>    <td>The lookup depth in the HTTP protocol module low-level cache.</td></tr>   </tbody></table>      <h3>Event logging</h3>      <p>The known event logging facilities and modules are described   below.</p>      <dl> +  + <dt>Facility: roxen</dt> +  <dd><p>This is logging for systems in the Roxen WebServer core. +  For logging that is not related to any specific configuration, the +  configuration for the Administration Interface is used.</p> +  +  <p>The known events are:</p> +  +  <table><tbody valign='top'> +  <tr><td>ram-cache-gc</td> +  <td>Logged after the RAM cache GC has run. $handle-time and +  $handle-cputime are set to the time the GC took (see +  descriptions above for details).</td></tr> +  <tr><td>ram-cache-rebase</td> +  <td>Logged when the RAM cache has performed a rebias of the +  priority queue values. Is a problem only if it starts to +  happen too often.</td></tr> +  </tbody></table></dd> +    <dt>Facility: sbfs</dt>    <dd><p>A SiteBuilder file system.</p>       <p>The actions <code>commit</code>, <code>purge</code>,    <code>mkdir</code>, <code>set-dir-md</code>, and    <code>rmdir</code> are logged for file system changes except those    in edit areas.</p>       <p>The action <code>crawl-file</code> is logged for files that are    crawled by the persistent cache crawler.</p>
Roxen.git/server/translations/eng/roxen_config.xml:3492:      <str id="1040">   <o>Note: This schedule is also used to schedule backups for Roxen's internal databases.</o>   <t></t>   </str>      <str id="1041">   <o>Are you sure you want to restore the default value?</o>   <t></t>   </str> +  + <str id="1043"> + <o>Cache: Memory cache size</o> + <t></t> + </str> +  + <str id="1044"> + <o>&lt;p&gt;Maximum size in MByte for all RAM caches taken together. This limit + covers the caches visible in the &lt;a + href='/actions/?action=cachestatus.pike&amp;class=status'&gt;Cache status&lt;/a&gt; + page.&lt;/p&gt; +  + &lt;p&gt;Note that there are many more things in the Roxen WebServer that + take space, including some caches that are not handled by the common + RAM cache. Also, there is various indirect memory overhead that is not + directly accounted for by the size calculations. All these taken + together means that the figure configured here cannot be mapped + straightly to the size of the Roxen process as reported by the OS. The + optimal setting here is the one that in general keeps the Roxen + process at a size that avoids swapping and leaves enough memory for + buffers and other processes that need to run at the same time (e.g. + the Roxen instance of the MySQL server).&lt;/p&gt;</o> + <t></t> + </str> +  + <str id="1045"> + <o>Cache: Memory cache GC interval</o> + <t></t> + </str> +  + <str id="1046"> + <o>&lt;p&gt;Interval in seconds between RAM cache garbage collector runs. This + GC removes entries from the RAM caches that have timed out or are + stale for other reasons, thereby making more room for new entries. The + configured cache size limits are enforced when entries are added, so + this GC is not required to keep the cache sizes down.&lt;/p&gt; +  + &lt;p&gt;Running this GC too seldom causes some RAM caches to contain many + invalid cache entries, which could push out valid cache entries. + Running it too often causes unnecessary server load.&lt;/p&gt;</o> + <t></t> + </str>