Re: [opensuse-factory] ZMD consumes 70-85% cpu during more than 150 minutes...
Reply on 06-11-2006 15:14:12 <<<> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Dominique Leuenberger schreef:
Reply on 06-11-2006 14:51:33 <<<> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
As subject,
2958 root 34 19 215m 12m 3428 R 80.2 2.6 55:03.02 zmd 2958 root 34 19 215m 15m 3860 R 79.6 3.2 118:37.63 zmd 2958 root 34 19 215m 15m 3856 R 76.7 3.2 162:21.22 zmd
Hey,
do we have to expect such a mail every few minutes now on the
Maybe the best would be to open a BugZilla tracker or find out what happened?
Will help you and everybody much more than having this message every few minutes.
Greetings, Dominique
Is that the reason why you sent the same message twice? Or are you in some way compelled with zmd, so you do not want to see the app is invalid?
What I am trying to prove with this, is that the app is useless at
time, (as it was in 101), and that we all need something like smart, and smart update checker, instead of this resources consuming monster,
list? this that
is not productive at all....
I think one problem we all experiance here (and I'm not even sure Smart would handle this different) is the fact, the a zmd refresh has to get the current catalog infos from a server (I think it's downloading primary.xml.gz and filelists.xml.gz and maybe even other.xml.gz, can a ZMD expert comment on this?) Especially in the Factory tree which is very unstable at the moment, these catalog files are changing regularly (several times a week) and thus have to be downloaded over and over again. Once the tree is considered stable, these catalogs get downloaded a single time and only the update tree is modified. AFAIK, zmd keeps the timestamps of the last update of these catalogs, and if not changed, decides not to download them. A short look on the files show, that it is downloading around 60MB at the moment. This might take a while. Here, probably the FTP/HTTP[S] Get method is not as cpu friendly as it could be, or maybe it's something completely different. Maybe some zmd guy could comment on this? Or maybe I should start digging around in the sources :-) Greetings, Dominique
I think one problem we all experiance here (and I'm not even sure Smart would handle this different) is the fact, the a zmd refresh has to get the current catalog infos from a server (I think it's downloading primary.xml.gz and filelists.xml.gz and maybe even other.xml.gz, can a ZMD expert comment on this?)
Especially in the Factory tree which is very unstable at the moment, these catalog files are changing regularly (several times a week) and thus have to be downloaded over and over again.
Once the tree is considered stable, these catalogs get downloaded a single time and only the update tree is modified. AFAIK, zmd keeps the timestamps of the last update of these catalogs, and if not changed, decides not to download them.
A short look on the files show, that it is downloading around 60MB at the moment. This might take a while. Here, probably the FTP/HTTP[S] Get method is not as cpu friendly as it could be, or maybe it's something completely different.
Its not downloading other.xml.gz usually, but all else if it has changed. Ciao, Marcus --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Dominique Leuenberger schrieb:
I think one problem we all experiance here (and I'm not even sure Smart would handle this different) is the fact, the a zmd refresh has to get the current catalog infos from a server (I think it's downloading primary.xml.gz and filelists.xml.gz and maybe even other.xml.gz, can a ZMD expert comment on this?)
Almost true. ;-) zmd never downloads other.xml.gz. If it does, it's a bug. But I've never seen that. zmd and smart are downloading the same files for YUM repos: repomd.xml, primary.xml.gz and filelists.xml.gz. The difference is that zmd downloads it even if not explicitly asked to do so. But on the other hand, the files don't need to be downloaded later because they are already available.
Especially in the Factory tree which is very unstable at the moment, these catalog files are changing regularly (several times a week) and thus have to be downloaded over and over again.
Let's say that the tree is "in flux" and not "unstable".
Once the tree is considered stable, these catalogs get downloaded a single time and only the update tree is modified. AFAIK, zmd keeps the timestamps of the last update of these catalogs, and if not changed, decides not to download them.
Correct, neither zmd nor smart are downloading metadata from unchanged sources again if they are already available.
A short look on the files show, that it is downloading around 60MB at the moment. This might take a while. Here, probably the FTP/HTTP[S] Get method is not as cpu friendly as it could be, or maybe it's something completely different.
There is a slight difference between zmd/YaST/zypp and smart for YaST sources: For this source type, smart does indeed download fewer files than libzypp does. But you get less functionality back: No translations, no disk usage information, no patterns. What Monkey 9 is experiencing here is probably just a bad mirror. I blame download.suse.com. Solution: Remove this source and add a good mirror directly. Andreas --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andreas Hanke schreef:
Dominique Leuenberger schrieb:
I think one problem we all experiance here (and I'm not even sure Smart would handle this different) is the fact, the a zmd refresh has to get the current catalog infos from a server (I think it's downloading primary.xml.gz and filelists.xml.gz and maybe even other.xml.gz, can a ZMD expert comment on this?)
Almost true. ;-)
zmd never downloads other.xml.gz. If it does, it's a bug. But I've never seen that.
zmd and smart are downloading the same files for YUM repos: repomd.xml, primary.xml.gz and filelists.xml.gz. The difference is that zmd downloads it even if not explicitly asked to do so. But on the other hand, the files don't need to be downloaded later because they are already available.
Especially in the Factory tree which is very unstable at the moment, these catalog files are changing regularly (several times a week) and thus have to be downloaded over and over again.
Let's say that the tree is "in flux" and not "unstable".
Once the tree is considered stable, these catalogs get downloaded a single time and only the update tree is modified. AFAIK, zmd keeps the timestamps of the last update of these catalogs, and if not changed, decides not to download them.
Correct, neither zmd nor smart are downloading metadata from unchanged sources again if they are already available.
A short look on the files show, that it is downloading around 60MB at the moment. This might take a while. Here, probably the FTP/HTTP[S] Get method is not as cpu friendly as it could be, or maybe it's something completely different.
There is a slight difference between zmd/YaST/zypp and smart for YaST sources: For this source type, smart does indeed download fewer files than libzypp does.
But you get less functionality back: No translations, no disk usage information, no patterns.
What Monkey 9 is experiencing here is probably just a bad mirror. I blame download.suse.com. Solution: Remove this source and add a good mirror directly.
The process was just there after the updater shutted down.. The reason for the shutdown is allready known. The only tool i have to see what is happening at this moment is top. I agree it is vague, but one kan kill a process before completely stuck...(if one is lucky) I killed it.. My question right now is: which app do i need, and can be used on 102, to find out what is realy happening? In 101 i just uninstalled, but now this is not possible without a lot of dependencies-trouble. I can offcourse reinstall the whole bunch, uninstall the whole circus: zyplibb, rug and zmd immediately, but what do we gain from this?
Andreas
M9.
--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFFT0EnX5/X5X6LpDgRAjJaAKCW+GJ9vdoybEcfqqrqsX5Ot0OVqQCeJp81 jOFWVjPHR8JQPcXwmDW59ZI= =fVEa -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dominique Leuenberger schreef:
Reply on 06-11-2006 15:14:12 <<<> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Dominique Leuenberger schreef:
Reply on 06-11-2006 14:51:33 <<<> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
As subject,
2958 root 34 19 215m 12m 3428 R 80.2 2.6 55:03.02 zmd 2958 root 34 19 215m 15m 3860 R 79.6 3.2 118:37.63 zmd 2958 root 34 19 215m 15m 3856 R 76.7 3.2 162:21.22 zmd
Hey,
do we have to expect such a mail every few minutes now on the
Maybe the best would be to open a BugZilla tracker or find out what happened?
Will help you and everybody much more than having this message every few minutes.
Greetings, Dominique Is that the reason why you sent the same message twice? Or are you in some way compelled with zmd, so you do not want to see
list? the app is invalid?
What I am trying to prove with this, is that the app is useless at this time, (as it was in 101), and that we all need something like smart, and smart update checker, instead of this resources consuming monster, that is not productive at all....
I think one problem we all experiance here (and I'm not even sure Smart would handle this different) is the fact, the a zmd refresh has to get the current catalog infos from a server (I think it's downloading primary.xml.gz and filelists.xml.gz and maybe even other.xml.gz, can a ZMD expert comment on this?)
Especially in the Factory tree which is very unstable at the moment, these catalog files are changing regularly (several times a week) and thus have to be downloaded over and over again.
Once the tree is considered stable, these catalogs get downloaded a single time and only the update tree is modified. AFAIK, zmd keeps the timestamps of the last update of these catalogs, and if not changed, decides not to download them.
A short look on the files show, that it is downloading around 60MB at the moment. This might take a while. Here, probably the FTP/HTTP[S] Get method is not as cpu friendly as it could be, or maybe it's something completely different.
It was not downloading anything, nor doing anything I commanded it to do, that's why I think it is very unusual, to take this much resources, for such a long time.
Maybe some zmd guy could comment on this? Or maybe I should start digging around in the sources :-)
Greetings, Dominique
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFFTzwUX5/X5X6LpDgRAiFXAJ0YvX6fbG9iPXOKT0ewjMbHrNjBcQCeNS9b hXpiNS2j73aDOLTp1HFJirw= =XLaK -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
participants (4)
-
Andreas Hanke -
Dominique Leuenberger -
Marcus Meissner -
Robby (M9.) Verberne