Mainly while the main page is loading it takes awhile. Any problems?

---

Doesn't expecting the unexpected make the unexpected the expected?
If it makes sense, DON'T do it.

Mainly while the main page is loading it takes awhile. Any problems?

i think the web server has trouble sometimes when the server is really busy validating workunits and such. In the future we may move the web server to a separate machine.

---

Dave Przybylo
MilkyWay@home Developer
Department of Computer Science
Rensselaer Polytechnic Institute

Ok.

---

Doesn't expecting the unexpected make the unexpected the expected?
If it makes sense, DON'T do it.

Been extremely slow last 36 hours. Most of the time it takes a few refresh's to get a page to load. But do get little bursts of speed.

---

Doesn't expecting the unexpected make the unexpected the expected?
If it makes sense, DON'T do it.

Been extremely slow last 36 hours. Most of the time it takes a few refresh's to get a page to load. But do get little bursts of speed.

I would support this comment by banditwolf - very slow and multiple refreshes

We're having a problem where the harddrive of milkyway isn't quite big enough, so stuff is spilling over to the NFS server, which is slowing things down. We've ordered a bunch more hard drives which should fix the problem.

---

For atleast 18+ hours now the site has been going very slow. Doesn't seem to have benifitted from the recent changes. I can't even get this to post. (3rd try,(can't beat copy/paste))

---

Doesn't expecting the unexpected make the unexpected the expected?
If it makes sense, DON'T do it.

We're having a problem where the harddrive of milkyway isn't quite big enough, so stuff is spilling over to the NFS server, which is slowing things down. We've ordered a bunch more hard drives which should fix the problem.

Hmmm...

I wonder if some of the feeder queue is spilling over to NFS. I've had task DL's balking initially from time to time since the quota adjustment.

Alinator

We're having a problem where the harddrive of milkyway isn't quite big enough, so stuff is spilling over to the NFS server, which is slowing things down. We've ordered a bunch more hard drives which should fix the problem.

Hmmm...

I wonder if some of the feeder queue is spilling over to NFS. I've had task DL's balking initially from time to time since the quota adjustment.

Alinator

Yea, could be. Going fast at the moment.

---

Doesn't expecting the unexpected make the unexpected the expected?
If it makes sense, DON'T do it.

Well, it looks like Travis is tweaking things. :-)

I just got a down for maintenance 1 hour buzz off when one of my hosts tried to report right after he posted. ;-)

Alinator

Well, it looks like Travis is tweaking things. :-)

I just got a down for maintenance 1 hour buzz off when one of my hosts tried to report right after he posted. ;-)

Alinator

I think part of it is i stopped the old assimilator from generating new workunits and moved the new app out of test mode. The daemons for the new app are a lot faster. I wrote a custom assimilator for what we're doing which is a lot faster and memory friendly than the old one. The WUs being generated now should also take more time which should hopefully keep the server and all the WU hungry cpus out there happy.

---

The last day especially, the site is slow most of the time. At times I can't get the page to load. My guess is due to more users looking for new apps, or just more users & wu's out at a time, is being slowed when groups are returned at the same time.

---

Doesn't expecting the unexpected make the unexpected the expected?
If it makes sense, DON'T do it.

I think it's currently related to the bug I'm encountering, if it's widespread : since my computers think that every WU take a very little time (about 10 min), they try to ask the server for WUs, again and again (even if the server replies that there's already too much WU for this computer)

If widespread, I think it could make a heavy load on the server.

http://milkyway.cs.rpi.edu/milkyway/forum_thread.php?id=606

Well, the note on the front page indicated that there was a miscalculation on the "size" of the tasks and this will throw off BOINC until it can get it sorted out again. I just did a manual change to the client state so that I can get all my long list in before the deadline, a kind of forced "push" as BOINC did not seem to be noticing yet that all the tasks were in deadline peril ...

Anyway, I am clearing my backlog at 6 per cycle with at least 3 hours to get them all ... then hopefully it will settle in to doing them in the small streams that it should ... :)

Well, the note on the front page indicated that there was a miscalculation on the "size" of the tasks and this will throw off BOINC until it can get it sorted out again. I just did a manual change to the client state so that I can get all my long list in before the deadline, a kind of forced "push" as BOINC did not seem to be noticing yet that all the tasks were in deadline peril ...

Anyway, I am clearing my backlog at 6 per cycle with at least 3 hours to get them all ... then hopefully it will settle in to doing them in the small streams that it should ... :)

That has to do with the size not being changed in a long time, since the wu's have changed it gives much larger run times initially. Now the 'size' given is too small to start with. Though so have said there is wu's that give 200+ hours as the run time.

---

Doesn't expecting the unexpected make the unexpected the expected?
If it makes sense, DON'T do it.

I have noticed very slow webpage response especially for the last couple of days as well....

---

I am the Kittyman.

Please visit and give a Click for Seti City.

Yes the page is very slow to load at times. It has something to do with what a previous user said about the boinc application querying the server repeatedly and causing excess load i believe.

---

Dave Przybylo
MilkyWay@home Developer
Department of Computer Science
Rensselaer Polytechnic Institute

Yes the page is very slow to load at times. It has something to do with what a previous user said about the boinc application querying the server repeatedly and causing excess load i believe.

This should get better as the boinc clients get adjusted to the new fpops estimate in the workunits.

---

Yes the page is very slow to load at times. It has something to do with what a previous user said about the boinc application querying the server repeatedly and causing excess load i believe.

This should get better as the boinc clients get adjusted to the new fpops estimate in the workunits.

I don't think so, if the cache is set to more days than the 12/core last, the client will request more every couple of minutes.

---

mic.

Yes the page is very slow to load at times. It has something to do with what a previous user said about the boinc application querying the server repeatedly and causing excess load i believe.

This should get better as the boinc clients get adjusted to the new fpops estimate in the workunits.

I don't think so, if the cache is set to more days than the 12/core last, the client will request more every couple of minutes.

True, but I don't think a host which is exceeding the in progress limit triggers a DB query. The scheduler looks to see if it would even be eligible for more work, and if not gives it a come back later 'dust off'.

Of course, some of the big gun battleships are knocking off the bandits every ten minutes of so, and thus need more targets to shoot at frequently. ;-)

Alinator