On the node3 there are 6 VMs= =3D with 72 GB of memory. But the supervdsm server use only 1.7% of memory.

Does anyone know why?

<= =3D /div>

[ro= ot(a)n=3D ode0 ~]# ps aux|grep supervdsmServer
root 19549 0.2 20.8 26248348 859435= =3D 2 ? S<l 06:00 1:59 /usr/bin/python /usr/share/vdsm/supervdsmServer --soc= =3D kfile /var/run/vdsm/svdsm.sock --pidfile /var/run/vdsm/supervdsmd.pid

[root(a)node1 ~]# ps= aux|g=3D rep supervdsmServer
root 32701 1.2 29.5 32463704 9717368 ? S<l 03:59 = =3D 12:08 /usr/bin/python /usr/share/vdsm/supervdsmServer --sockfile /var/run/v= =3D dsm/svdsm.sock --pidfile /var/run/vdsm/supervdsmd.pid

[root(a)node2 ~]# ps aux|grep supervdsmSer= ver<=3D br>root 4613 0.0 1.7 6340572 1291476 ? S<l 18:26 0:04 /usr/bin/python /u= =3D sr/share/vdsm/supervdsmServer --sockfile /var/run/vdsm/svdsm.sock --pidfile= =3D /var/run/vdsm/supervdsmd.pid
=

Thanks in advance=3D

<= p st=3D yle=3D3D"margin: 0px;" data-mce-style=3D3D"margin: 0px;">Tibor

=3D

------=3D_Part_670523_2123662085.1417548535072-- --===============4136657356164774725== Content-Type: multipart/alternative MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.bin" LS0tLS0tPV9QYXJ0XzY3MDUyM18yMTIzNjYyMDg1LjE0MTc1NDg1MzUwNzIKQ29udGVudC1UeXBl OiB0ZXh0L3BsYWluOyBjaGFyc2V0PXV0Zi04CkNvbnRlbnQtVHJhbnNmZXItRW5jb2Rpbmc6IDdi aXQKCkhpLCAKCldlIGhhdmUgYSBwcm9kdWN0aXZlIG92aXJ0IDMuNSBjbHVzdGVyIHdpdGggMyBu b2Rlcy4gCgpUaGUgZmlyc3Qgbm9kZSBoYXMgNDAgZ2Igb2YgbWVtb3J5IGFuZCBydW5uaW5nIG9u bHkgb25lIFZNIHRoYXQgdXNlIDggZ2Igb2YgcmFtLiAKQnV0IHRoZSBzdXBlcnZkc21zZXJ2ZXIg Y29uc3VtZXMgMjAlIG9mIGhvc3QgbWVtb3J5LiAKT24gdGhlIHNlY29uZCBub2RlIGhhcyAzMiBH QiBvZiBtZW1vcnkgd2l0aCA1IFZNcy4gT24gdGhpcyBub2RlIHRoZSBzdXBlcnZkc21zZXJ2ZXIg dXNpbmcgMzAlKCEpIG9mIG1lbW9yeSEgCk9uIHRoZSBub2RlMyB0aGVyZSBhcmUgNiBWTXMgd2l0 aCA3MiBHQiBvZiBtZW1vcnkuIEJ1dCB0aGUgc3VwZXJ2ZHNtIHNlcnZlciB1c2Ugb25seSAxLjcl IG9mIG1lbW9yeS4gCgpEb2VzIGFueW9uZSBrbm93IHdoeT8gCgoKCgpbcm9vdEBub2RlMCB+XSMg cHMgYXV4fGdyZXAgc3VwZXJ2ZHNtU2VydmVyIApyb290IDE5NTQ5IDAuMiAyMC44IDI2MjQ4MzQ4 IDg1OTQzNTIgPyBTPGwgMDY6MDAgMTo1OSAvdXNyL2Jpbi9weXRob24gL3Vzci9zaGFyZS92ZHNt L3N1cGVydmRzbVNlcnZlciAtLXNvY2tmaWxlIC92YXIvcnVuL3Zkc20vc3Zkc20uc29jayAtLXBp ZGZpbGUgL3Zhci9ydW4vdmRzbS9zdXBlcnZkc21kLnBpZCAKCgoKCgpbcm9vdEBub2RlMSB+XSMg cHMgYXV4fGdyZXAgc3VwZXJ2ZHNtU2VydmVyIApyb290IDMyNzAxIDEuMiAyOS41IDMyNDYzNzA0 IDk3MTczNjggPyBTPGwgMDM6NTkgMTI6MDggL3Vzci9iaW4vcHl0aG9uIC91c3Ivc2hhcmUvdmRz bS9zdXBlcnZkc21TZXJ2ZXIgLS1zb2NrZmlsZSAvdmFyL3J1bi92ZHNtL3N2ZHNtLnNvY2sgLS1w aWRmaWxlIC92YXIvcnVuL3Zkc20vc3VwZXJ2ZHNtZC5waWQgCgoKCgpbcm9vdEBub2RlMiB+XSMg cHMgYXV4fGdyZXAgc3VwZXJ2ZHNtU2VydmVyIApyb290IDQ2MTMgMC4wIDEuNyA2MzQwNTcyIDEy OTE0NzYgPyBTPGwgMTg6MjYgMDowNCAvdXNyL2Jpbi9weXRob24gL3Vzci9zaGFyZS92ZHNtL3N1 cGVydmRzbVNlcnZlciAtLXNvY2tmaWxlIC92YXIvcnVuL3Zkc20vc3Zkc20uc29jayAtLXBpZGZp bGUgL3Zhci9ydW4vdmRzbS9zdXBlcnZkc21kLnBpZCAKCgoKCgpUaGFua3MgaW4gYWR2YW5jZSAK CgoKClRpYm9yIAoKCgoKCgotLS0tLS09X1BhcnRfNjcwNTIzXzIxMjM2NjIwODUuMTQxNzU0ODUz NTA3MgpDb250ZW50LVR5cGU6IHRleHQvaHRtbDsgY2hhcnNldD11dGYtOApDb250ZW50LVRyYW5z ZmVyLUVuY29kaW5nOiBxdW90ZWQtcHJpbnRhYmxlCgo8aHRtbD48Ym9keT48ZGl2IHN0eWxlPTNE ImZvbnQtZmFtaWx5OiB0aW1lcyBuZXcgcm9tYW4sIG5ldyB5b3JrLCB0aW1lcywgc2U9CnJpZjsg Zm9udC1zaXplOiAxMnB0OyBjb2xvcjogIzAwMDAwMCI+PGRpdj5IaSw8L2Rpdj48ZGl2Pjxicj48 L2Rpdj48ZGl2PldlID0KaGF2ZSBhIHByb2R1Y3RpdmUgb3ZpcnQgMy41IGNsdXN0ZXIgd2l0aCAz IG5vZGVzLjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PQpUaGUgZmlyc3Qgbm9kZSBoYXMgNDAg Z2Igb2YgbWVtb3J5IGFuZCBydW5uaW5nIG9ubHkgb25lIFZNIHRoYXQgdXNlIDggZ2Igb2Y9CiBy YW0uPC9kaXY+PGRpdj5CdXQgdGhlIHN1cGVydmRzbXNlcnZlciBjb25zdW1lcyAyMCUgb2YgaG9z dCBtZW1vcnkuPC9kaXY+PD0KZGl2Pk9uIHRoZSBzZWNvbmQgbm9kZSBoYXMgMzIgR0Igb2YgbWVt b3J5IHdpdGggNSBWTXMuIE9uIHRoaXMgbm9kZSB0aGUgc3VwPQplcnZkc21zZXJ2ZXIgdXNpbmcg MzAlKCEpIG9mIG1lbW9yeSE8L2Rpdj48ZGl2Pk9uIHRoZSBub2RlMyB0aGVyZSBhcmUgNiBWTXM9 CiB3aXRoIDcyIEdCIG9mIG1lbW9yeS4gQnV0IHRoZSBzdXBlcnZkc20gc2VydmVyIHVzZSBvbmx5 IDEuNyUgb2YgbWVtb3J5LjwvZD0KaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5Eb2VzIGFueW9uZSBr bm93IHdoeT88L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48PQovZGl2PjxkaXY+PHAgc3R5 bGU9M0QibWFyZ2luOiAwcHg7IiBkYXRhLW1jZS1zdHlsZT0zRCJtYXJnaW46IDBweDsiPltyb290 QG49Cm9kZTAgfl0jIHBzIGF1eHxncmVwIHN1cGVydmRzbVNlcnZlcjxicj5yb290IDE5NTQ5IDAu MiAyMC44IDI2MjQ4MzQ4IDg1OTQzNT0KMiA/IFMmbHQ7bCAwNjowMCAxOjU5IC91c3IvYmluL3B5 dGhvbiAvdXNyL3NoYXJlL3Zkc20vc3VwZXJ2ZHNtU2VydmVyIC0tc29jPQprZmlsZSAvdmFyL3J1 bi92ZHNtL3N2ZHNtLnNvY2sgLS1waWRmaWxlIC92YXIvcnVuL3Zkc20vc3VwZXJ2ZHNtZC5waWQ8 YnI+PC89CnA+PHAgc3R5bGU9M0QibWFyZ2luOiAwcHg7IiBkYXRhLW1jZS1zdHlsZT0zRCJtYXJn aW46IDBweDsiPjxicj48L3A+PHAgc3R5bD0KZT0zRCJtYXJnaW46IDBweDsiIGRhdGEtbWNlLXN0 eWxlPTNEIm1hcmdpbjogMHB4OyI+W3Jvb3RAbm9kZTEgfl0jIHBzIGF1eHxnPQpyZXAgc3VwZXJ2 ZHNtU2VydmVyPGJyPnJvb3QgMzI3MDEgMS4yIDI5LjUgMzI0NjM3MDQgOTcxNzM2OCA/IFMmbHQ7 bCAwMzo1OSA9CjEyOjA4IC91c3IvYmluL3B5dGhvbiAvdXNyL3NoYXJlL3Zkc20vc3VwZXJ2ZHNt U2VydmVyIC0tc29ja2ZpbGUgL3Zhci9ydW4vdj0KZHNtL3N2ZHNtLnNvY2sgLS1waWRmaWxlIC92 YXIvcnVuL3Zkc20vc3VwZXJ2ZHNtZC5waWQ8L3A+PHAgc3R5bGU9M0QibWFyZ2luPQo6IDBweDsi IGRhdGEtbWNlLXN0eWxlPTNEIm1hcmdpbjogMHB4OyI+PGJyPjwvcD48cCBzdHlsZT0zRCJtYXJn aW46IDBweDsiIGQ9CmF0YS1tY2Utc3R5bGU9M0QibWFyZ2luOiAwcHg7Ij5bcm9vdEBub2RlMiB+ XSMgcHMgYXV4fGdyZXAgc3VwZXJ2ZHNtU2VydmVyPD0KYnI+cm9vdCA0NjEzIDAuMCAxLjcgNjM0 MDU3MiAxMjkxNDc2ID8gUyZsdDtsIDE4OjI2IDA6MDQgL3Vzci9iaW4vcHl0aG9uIC91PQpzci9z aGFyZS92ZHNtL3N1cGVydmRzbVNlcnZlciAtLXNvY2tmaWxlIC92YXIvcnVuL3Zkc20vc3Zkc20u c29jayAtLXBpZGZpbGU9CiAvdmFyL3J1bi92ZHNtL3N1cGVydmRzbWQucGlkPGJyPjxzcGFuIHN0 eWxlPTNEImZvbnQtc2l6ZTogMTJwdDsiPjwvc3Bhbj48Lz0KcD48cCBzdHlsZT0zRCJtYXJnaW46 IDBweDsiIGRhdGEtbWNlLXN0eWxlPTNEIm1hcmdpbjogMHB4OyI+PHNwYW4gc3R5bGU9M0QiPQpm b250LXNpemU6IDEycHQ7Ij48YnI+PC9zcGFuPjwvcD48cCBzdHlsZT0zRCJtYXJnaW46IDBweDsi IGRhdGEtbWNlLXN0eWxlPQo9M0QibWFyZ2luOiAwcHg7Ij48c3BhbiBzdHlsZT0zRCJmb250LXNp emU6IDEycHQ7Ij5UaGFua3MgaW4gYWR2YW5jZTwvc3Bhbj49CjwvcD48cCBzdHlsZT0zRCJtYXJn aW46IDBweDsiIGRhdGEtbWNlLXN0eWxlPTNEIm1hcmdpbjogMHB4OyI+PGJyPjwvcD48cCBzdD0K eWxlPTNEIm1hcmdpbjogMHB4OyIgZGF0YS1tY2Utc3R5bGU9M0QibWFyZ2luOiAwcHg7Ij5UaWJv cjwvcD48cCBzdHlsZT0zRCJtPQphcmdpbjogMHB4OyIgZGF0YS1tY2Utc3R5bGU9M0QibWFyZ2lu OiAwcHg7Ij48YnI+PC9wPjwvZGl2PjxkaXY+PHNwYW4gbmFtZT0KPTNEIngiPjwvc3Bhbj48cCBz dHlsZT0zRCJmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IGZvbnQtc2l6ZTogbWVkaXVt PQo7IG1hcmdpbjogMHB4OyIgZGF0YS1tY2Utc3R5bGU9M0QiZm9udC1mYW1pbHk6ICdUaW1lcyBO ZXcgUm9tYW4nOyBmb250LXNpemU9CjogbWVkaXVtOyBtYXJnaW46IDBweDsiPjxzdHJvbmc+PHNw YW4gc3R5bGU9M0QiZm9udC1zaXplOiBtZWRpdW07IiBkYXRhLW1jZT0KLXN0eWxlPTNEImZvbnQt c2l6ZTogbWVkaXVtOyI+PHNwYW4gc2l6ZT0zRCI1IiBjb2xvcj0zRCIjMkQ2N0IwIiBzdHlsZT0z RCJjPQpvbG9yOiByZ2IoNDUsIDEwMywgMTc2KTsiIGRhdGEtbWNlLXN0eWxlPTNEImNvbG9yOiAj MmQ2N2IwOyI+PC9zcGFuPjwvc3Bhbj49Cjwvc3Ryb25nPjwvcD48L2Rpdj48L2Rpdj48L2JvZHk+ PC9odG1sPgotLS0tLS09X1BhcnRfNjcwNTIzXzIxMjM2NjIwODUuMTQxNzU0ODUzNTA3Mi0tCg== --===============4136657356164774725==-- From danken at redhat.com Tue Dec 2 16:15:42 2014 Content-Type: multipart/mixed; boundary="===============2557096101185918681==" MIME-Version: 1.0 From: Dan Kenigsberg To: users at ovirt.org Subject: Re: [ovirt-users] supervdsmServer consumes 30% of host memory Date: Tue, 02 Dec 2014 21:15:32 +0000 Message-ID: <20141202211532.GO5847@redhat.com> In-Reply-To: 1210449455.670524.1417548535072.JavaMail.zimbra@itsmart.hu --===============2557096101185918681== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Tue, Dec 02, 2014 at 08:28:55PM +0100, Demeter Tibor wrote: > Hi, = > = > We have a productive ovirt 3.5 cluster with 3 nodes. = > = > The first node has 40 gb of memory and running only one VM that use 8 gb = of ram. = > But the supervdsmserver consumes 20% of host memory. = > On the second node has 32 GB of memory with 5 VMs. On this node the super= vdsmserver using 30%(!) of memory! = > On the node3 there are 6 VMs with 72 GB of memory. But the supervdsm serv= er use only 1.7% of memory. = > = > Does anyone know why? = most probably Bug 1142647 - supervdsm leaks memory when using glusterfs which would be fixed in ovirt-3.5.1. Unfortunately, it won't be released today - the released date has been postponed to Dec 9th. Since the two glusterfs issues (memleak and segfault) repeat so often, I've tagged vdsm-4.16.8 as a release candidate for ovirt-3.5.1. Sandro, could you help in building it and placing it somewhere for people to try it out? After all, it has 87 (!) patches since 3.5.0, so testing is due. Regards, Dan. --===============2557096101185918681==-- From sbonazzo at redhat.com Wed Dec 3 04:13:05 2014 Content-Type: multipart/mixed; boundary="===============0069961086156763028==" MIME-Version: 1.0 From: Sandro Bonazzola To: users at ovirt.org Subject: Re: [ovirt-users] supervdsmServer consumes 30% of host memory Date: Wed, 03 Dec 2014 10:12:57 +0100 Message-ID: <547ED419.9080804@redhat.com> In-Reply-To: 20141202211532.GO5847@redhat.com --===============0069961086156763028== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Il 02/12/2014 22:15, Dan Kenigsberg ha scritto: > On Tue, Dec 02, 2014 at 08:28:55PM +0100, Demeter Tibor wrote: >> Hi, = >> >> We have a productive ovirt 3.5 cluster with 3 nodes. = >> >> The first node has 40 gb of memory and running only one VM that use 8 gb= of ram. = >> But the supervdsmserver consumes 20% of host memory. = >> On the second node has 32 GB of memory with 5 VMs. On this node the supe= rvdsmserver using 30%(!) of memory! = >> On the node3 there are 6 VMs with 72 GB of memory. But the supervdsm ser= ver use only 1.7% of memory. = >> >> Does anyone know why? = > = > most probably > = > Bug 1142647 - supervdsm leaks memory when using glusterfs > = > which would be fixed in ovirt-3.5.1. Unfortunately, it won't be released > today - the released date has been postponed to Dec 9th. > = > Since the two glusterfs issues (memleak and segfault) repeat so often, > I've tagged vdsm-4.16.8 as a release candidate for ovirt-3.5.1. > = > Sandro, could you help in building it and placing it somewhere for > people to try it out? After all, it has 87 (!) patches since 3.5.0, so > testing is due. Dan, 4.16.8-0 has been already built in jenkins[1][2][3][4] and it has been= already published in 3.5 nightly snapshot[5]. Whoever want to test it is more than welcome. Instructions for using nightly are on the wiki [6]. Please add yourself to the testing report page [7] if you're going to test = it. [1] http://jenkins.ovirt.org/job/vdsm_3.5_create-rpms-el6-x86_64_merged/133/ [2] http://jenkins.ovirt.org/job/vdsm_3.5_create-rpms-el7-x86_64_merged/130/ [3] http://jenkins.ovirt.org/job/vdsm_3.5_create-rpms-fc19-x86_64_merged/13= 0/ [4] http://jenkins.ovirt.org/job/vdsm_3.5_create-rpms-fc20-x86_64_merged/13= 0/ [5] http://jenkins.ovirt.org/view/Publishers/job/publish_ovirt_rpms_nightly= _3.5/202/ [6] http://www.ovirt.org/Install_nightly_snapshot [7] http://www.ovirt.org/Testing/oVirt_3.5.1_Testing Thanks, > = > Regards, > Dan. > = -- = Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com --===============0069961086156763028==-- From daniel.helgenberger at m-box.de Wed Dec 3 05:40:36 2014 Content-Type: multipart/mixed; boundary="===============2533861916917883609==" MIME-Version: 1.0 From: Daniel Helgenberger To: users at ovirt.org Subject: Re: [ovirt-users] supervdsmServer consumes 30% of host memory Date: Wed, 03 Dec 2014 10:40:16 +0000 Message-ID: <55d783b1d8c04df184a8640b95f409d9@EXCHANGE.mbox.loc> In-Reply-To: 20141202211532.GO5847@redhat.com --===============2533861916917883609== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 02.12.2014 22:16, Dan Kenigsberg wrote: > On Tue, Dec 02, 2014 at 08:28:55PM +0100, Demeter Tibor wrote: >> Hi, >> >> We have a productive ovirt 3.5 cluster with 3 nodes. >> >> The first node has 40 gb of memory and running only one VM that use 8 gb= of ram. >> But the supervdsmserver consumes 20% of host memory. >> On the second node has 32 GB of memory with 5 VMs. On this node the supe= rvdsmserver using 30%(!) of memory! >> On the node3 there are 6 VMs with 72 GB of memory. But the supervdsm ser= ver use only 1.7% of memory. >> >> Does anyone know why? > > most probably > > Bug 1142647 - supervdsm leaks memory when using glusterfs > > which would be fixed in ovirt-3.5.1. Unfortunately, it won't be released > today - the released date has been postponed to Dec 9th. > > Since the two glusterfs issues (memleak and segfault) repeat so often, > I've tagged vdsm-4.16.8 as a release candidate for ovirt-3.5.1. > > Sandro, could you help in building it and placing it somewhere for > people to try it out? After all, it has 87 (!) patches since 3.5.0, so > testing is due. Good to know! Giving it a shot, upgrading went smoothly so far. I'll = report back if something comes up. > > Regards, > Dan. > _______________________________________________ > Users mailing list > Users(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/users > -- = Daniel Helgenberger m box bewegtbild GmbH P: +49/30/2408781-22 F: +49/30/2408781-10 ACKERSTR. 19 D-10115 BERLIN www.m-box.de www.monkeymen.tv Gesch=C3=A4ftsf=C3=BChrer: Martin Retschitzegger / Michaela G=C3=B6llner Handeslregister: Amtsgericht Charlottenburg / HRB 112767 --===============2533861916917883609==--