Mailing-List: contact users-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@activemq.apache.org
MIME-Version: 1.0
References: <DB6PR0602MB2823ED3C1A022BD4AD8610D3FB720@DB6PR0602MB2823.eurprd06.prod.outlook.com>
In-Reply-To: <DB6PR0602MB2823ED3C1A022BD4AD8610D3FB720@DB6PR0602MB2823.eurprd06.prod.outlook.com>
From: Clebert Suconic <clebert.suconic@gmail.com>
Date: Mon, 23 Jan 2017 15:34:19 +0000
Message-ID: <CAKF+bsproNetCcuv8gP0PrZLCi57dkPxxPAkT+K5GHf-9J8Mhw@mail.gmail.com>
Subject: Re: ARTEMIS: bad-performance behaviour after 7-10 days of usage
To: users@activemq.apache.org
Content-Type: multipart/alternative; boundary=001a114d799045d33a0546c4bc97
archived-at: Mon, 23 Jan 2017 15:34:46 -0000

--001a114d799045d33a0546c4bc97
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

A question. Are u consuming from the subscriptions or u intend to leave
them hinging?


While paging. Do u need transactions? If u start to page not using
transactions would make paging to act like partitions on Kafka.


I will be waiting for more data from you before we can help some more.


On Mon, Jan 23, 2017 at 5:55 AM Francesco PADOVANI <
Francesco.PADOVANI@bticino.it> wrote:

>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Hello,
>
>
> I'm using Apache Artemis as MQTT broker for our IOT projects.
>
>
> It's a clean Artemis installation of version 1.5.1., on a server (CentOS
> 7) which has 2 vCPU, 8 GB of RAM (4GB of Heap Space dedicated to Artemis)
> and 50 GB of SSD data disk.
>
>
> After the installation of artemis Broker we started to test it with about
> 10-15 clients constantly connected, 150 subscribed topics and an average =
of
> 2 messages per minute per client. I think these are not huge numbers, rig=
ht?
>
>
> For the few days after the installation, all was good and the broker
> worked perfectly: it was fast and reliable. But day by day performances
> have decreased and after about 10 days of usage it is became almost
> unusable: due to resources consumption. The following
>
> is my "top" situation on the server:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *top - 08:59:50 up 2 days, 22:09,  1 user,  load average: 2.56, 2.88,
> 3.00Tasks:  92 total,   1 running,  91 sleeping,   0 stopped,   0
> zombie%Cpu(s): 99.5 us,  0.5 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0
> si,  0.0 stKiB Mem :  7747288 total,   290968 free,  4697976 used,  27583=
44
> buff/cacheKiB Swap:        0 total,        0 free,        0 used.  273476=
8
> avail Mem  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM
> TIME+ COMMAND   4352 mqtt      20   0 7043380 4.348g  15192 S 200.0 58.9
> 6153:54
> java
>      1 root      20   0  128096   5176   2420 S   0.0  0.1   0:04.01
> systemd*
>
>
>
>
>
>
>
>
>
> Now I can see the broker starting to page on disk almost always. For sure
> it's a wrong configuration of ours. Currently, it seems that very old
> address/queue (and the related retained messages) are always kept, making
> memory and cpu consuption growing
>
> more and more. And even after a restart, the broker takes so much to get
> up.
>
> Before to become reachable, it starts to make many management operations
> like, for example, retrieve data from paging, etc.. But I also see the
> broker that starts to register old topics and queues we don't need. How t=
o
> clean them? How to make a topic/queue
>
> expire?
>
>
>
>
>
>
>
> Inside my broker.xml I did set up the parameter last-value-queue=3Dtrue,
> thinking that this was the problem ....but it doesn't solve. Or better:
> probably it's me that I've not understood the correct meaning of the
> parameter.
>
> I did check also the clients' parameters when they connect to the broker,
> to be sure they don't set, for example, clean-session =3D false (saying t=
he
> broker to keep all messages also when a client disconnects). But they mak=
e
> it in the right way. The only
>
> thing is that they don't specify a client-id. They connect by using a
> username/password and certificate (over tls). So, every time a client
> connects, Artemis automatically provide a random client-id for it (if I
> understood well).
>
>
> Attached you can find my broker.xml configuration file: it's pretty much
> the same default created during the installation procedure, but for the
> acceptors (which I've customized for my MQTT purpose) and the addition of
> parameter
>
> last-value-queue =3D true inside the address-setting
>
> section.
>
>
>
>
>
>
>
>
>
> Please: some of you could help me? How I have to configure my broker
> instance to understand and solve these performance issues?
>
>
>
>
>
>
>
> Thanks in advance
>
>
>
>
>
>
>
> Francesco
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ------------------------------
>
>
>
>
> Ce message, ainsi que tous les fichiers joints =C3=A0 ce message, peuvent
> contenir des informations sensibles et/ ou confidentielles ne devant pas
> =C3=AAtre divulgu=C3=A9es. Si vous n'=C3=AAtes pas le destinataire de ce =
message (ou que
> vous recevez ce message par erreur), nous
>
> vous remercions de le notifier imm=C3=A9diatement =C3=A0 son exp=C3=A9dit=
eur, et de
> d=C3=A9truire ce message. Toute copie, divulgation, modification, utilisa=
tion ou
> diffusion, non autoris=C3=A9e, directe ou indirecte, de tout ou partie de=
 ce
> message, est strictement interdite.
>
>
>
>
>
>
> This e-mail, and any document attached hereby, may contain confidential
> and/or privileged information. If you are not the intended recipient (or
> have received this e-mail in error) please notify the sender immediately
> and destroy this e-mail. Any unauthorized,
>
> direct or indirect, copying, disclosure, distribution or other use of the
> material or parts thereof is strictly forbidden.
>
>
>
>
>
>
>
>
>

--001a114d799045d33a0546c4bc97--