Слишком большой рост Nginx Client Stat с Nginx HTTP Push Module ...

[johnbat26 на gmail.com]

Привет всем.
Кто-нибудь использует Nginx HTTP Push Module ?
Мы его используем в качестве основы для доведения сообщений на клиент.
В принципе все хорошо. Но настораживает следующая вешь:
Раньше мы и спользовали back-end в качестве comet-сервера. 
Но потом, для экономии ресурсов (памяти и количества открытых сокетов) реорганизовали 
систему под использование вышеназванного плагина.
------------------
Наше окружение:
nginx: 0.7.65 (RHEL, CentOS  x86, X86-64);
nginx_http_push_plugin: 0.692b;
------------------
часть nginx.conf:
-----------------
 #proxy pass for comet       
      # internal publish endpoint (keep it private / protected)
        location /app1/v1/informing/pub {
         set $push_channel_id $arg_id;      #/?id=239aff3 or somesuch
         push_publisher;

         push_store_messages off;            # enable message queueing
         push_message_timeout 2h;           # expire buffered messages after 2 hours
         push_max_message_buffer_length 10; # store 10 messages
       # push_min_message_recipients 0;     # minimum recipients before purge
        }


      # public long-polling endpoint
        location  /app1/v1/informing/sub {
         set $push_channel_id $arg_id;
         push_subscriber;
         # how multiple listener requests to the same channel id are handled
         # - last: only the most recent listener request is kept, 409 for others.
         # - first: only the oldest listener request is kept, 409 for others.
         # - broadcast: any number of listener requests may be long-polling.
         push_subscriber_concurrency broadcast;
         #push_authorized_channels_only on;
         #push_max_channel_subscribers 1;
         default_type   application/x-javascript;
        }
----------------



Так вот, если посмотреть на приложенный график статистики, но видно что до использование плагина, количество Client Stat было небольшим.
Теперь же оно увеличились значительно и продолжает расти.
С чем это может быть связано.
ID канала у нас равно ID Http Session.
Может быть плагин не очищает устаревшие каналы?
Кто-нибудь может ответить на этот вопрос.

Сейчас один процесс nginx потребляет около 64 мб RAM.
-- 
Best Regards, Eugene Batogov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx-ru/attachments/20100802/09c7a310/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nginx_http_push_production.png
Type: image/png
Size: 38974 bytes
Desc: not available
URL: <http://nginx.org/pipermail/nginx-ru/attachments/20100802/09c7a310/attachment-0001.png>