![Sad :-(](./images/smilies/icon_sad.gif)
Project is down
Moderátor: Moderátori
-
- Príspevky: 1315
- Dátum registrácie: Ut Feb 06, 2007 1:35 am
- Bydlisko: Mooresville, NC
- Kontaktovať používateľa:
Project is down
Tak po istom case mi opat zvysili spravcovia projektu krvny tlak. Uz k tomu nemam co viac napisat. ![Sad :-(](./images/smilies/icon_sad.gif)
![Sad :-(](./images/smilies/icon_sad.gif)
-gabberattack-
Keep The Panic!
...a Windows Vista
padá na Mesiaci
6x pomalšie!
Keep The Panic!
...a Windows Vista
padá na Mesiaci
6x pomalšie!
- PPos
- Príspevky: 13
- Dátum registrácie: St Feb 14, 2007 8:17 pm
- Bydlisko: Pezinok
- Kontaktovať používateľa:
Uz to trva az prilis dlho. Ak niesu schopny za taky dlhy cas rozbehat projekt alebo ho zrusit tak sa mi to vidi ako pohrdanie tymi ktori im venuju procesorovi cas.slavko.sk napísal:Vysledky ti nezaratava prave preto ze maju problem s databazou. Bohuzial projekt je v poslednej dobe naozaj padavy. Snad ho konecne daju poriadne dokopy.
Na cca50% strojoch som ten projekt zastavil.
Jo, kazdy projekt si obcas zazije nejaky ten vypadek.
CPDN to ma take za sebou - treba preplneny upload server a podobne. Jenom u dlouhych jednotek to nebyva problem.
Jsou masiny pripojene k Einsteinovi na suchu?
Mam na nem dva Core 2 Duo masiny, ke kterym nemam pravidelny pristup. Ale nevsiml jsem si, ze by byly na suchu (zasoby na 2 dny).
U SETI se stavalo, ze bylo down nekolik dni na download i upload a nekolik hodin po nahozeni serveru stejne nedostupne kvuli pretizeni.
Pokud maji masiny co pocitat a vysledky se vrati projektu, je to hlavni.
Jestli prijde kredit zitra nebo po vikendu je mi jedno.
Ale zase nemohou pokouset trpelivost useru ad infinitum.
CPDN to ma take za sebou - treba preplneny upload server a podobne. Jenom u dlouhych jednotek to nebyva problem.
Jsou masiny pripojene k Einsteinovi na suchu?
Mam na nem dva Core 2 Duo masiny, ke kterym nemam pravidelny pristup. Ale nevsiml jsem si, ze by byly na suchu (zasoby na 2 dny).
U SETI se stavalo, ze bylo down nekolik dni na download i upload a nekolik hodin po nahozeni serveru stejne nedostupne kvuli pretizeni.
Pokud maji masiny co pocitat a vysledky se vrati projektu, je to hlavni.
Jestli prijde kredit zitra nebo po vikendu je mi jedno.
Ale zase nemohou pokouset trpelivost useru ad infinitum.
- azor666
- Príspevky: 51
- Dátum registrácie: Po Feb 05, 2007 9:28 pm
- Bydlisko: prague
- Kontaktovať používateľa:
Bruce napsal na EAH fórum co bylo příčinou problémů.
1)Projekt měl problémy s výkonem. Z důvodu přetížené databáze. Ta zpracovávala v průměru 950 žádostí za sekundu, nárazově až 3000.
Zapříčinil to způsob jakým pracuje BOINC scheduler a faktem, že při zpracování nové není mnoho jednotek s nízkou frekvenci. EAH je jediný projektem používajícím "locality scheduler" (jak to rozumně přeložít "místní scheduler" ) disajnovaný na rozesílání mnoha WU z jednoho datového souboru. Odesílá nový datový soubor jen když nezbývá žádná práce z předchozího. Co se stalo: Mnoho pomalých PC s soubory dat z malých frekvencí (jejich zpracování je rychlejší) žádalo práci pro tyto data. I když veškerá tato práce došla scheduler se jí snažil dál úporně hledat. Při prolézání celé databáze způsobilo její extrémní přetížení. 20% pomalých PC tedy generovalo obrovské množství přístupů do databáze při hledání neexistujících jednotek s nízkou frekvencí. Opravil jsem to (Bruce) pozměněním algoritmu na vyhledávání nové práce. Každý kdo se o to zajímá může se podívat příští týden na BOINC CVS.kdy zkontrolují upravený kód.
Zatížení databáze je nyní 60-80 žádostí za sekundu. Databázové servery a servery projektu jsou opět přístupné
2) Problém s file serverem. EAH využívá tři file servery, každý s kapacitou 8 TB diskového prostoru v RAID-6. File server užívá 24-portový SATA řadič Areca a Western Digital WD4000YR disky. Po několik měsíců jsme měli problémy. Disk se odpojil z pole. Když se po několika sekundách znova připojil vyžadoval obnovu diskového pole. Nakonec jsme jeden ze serverů (vážící 80 Kg o ceně 10K$) poslali expres poštou na Taiwan, kde se inženýři z Areca na problém důkladně podívali. (díky inženýrům za jejich prvotřídní podporu) Problém byl v HW-rový s disky WD4000YR. Jejich čip SATA rozhraní není (u některých revizí) kompatibilní s řadiči Arcea. Nekompatibilita se projevuje jen při použití NCQ. Problém byl tedy vyřešen vypnutím NCQ. Zbylé servery již jedou 14 dní bez problému.
Je to dlouhý jak Lovosice, tak to beru jen velmi stručně. Zhruba tam píše:[url=http://einstein.phys.uwm.edu/forum_thread.php?id=5411&nowrap=true#64707]Bruce Allen Project administrator Project scientist[/url] napísal:Dear Einstein@Home volunteers and contributors,
I thought I would post a description of what went wrong and how it was fixed.
(1) Project performance problems. These were due to our database getting overloaded. It was processing an average of 950 queries per second, with peaks of up to about 3000 queries per second. Ultimately, these were due to the way that the BOINC locality scheduler works and the fact that our new analysis run did not have many low-frequency workunits. Einstein@Home is the only project that uses the locality scheduler, which is designed to send many workunits for the same data file, only sending a new data file when there is no work left for the previous data file. What happened was that many hosts that had low frequency files (because they were slower than the majority of hosts) requested work for these files, or NEW workunits also for low frequency files. When the project ran out of work for these files, the locality scheduler would then perform an extremely database intensive 'crawl' through the database looking for more work. So the slowest 20% of hosts were generating very large numbers of database queries looking for non-existent low frequency workunits. I fixed this by modifying the algorithm that searches for new work. Anyone interested in the details can look at BOINC CVS next week when I check in the modified code.
The database is now averaging about 60 to 80 queries per second, and the database server and project servers are once again snappy and responsive.
(2) File server problems. Our project uses three file servers, each of which has about 8TB of RAID-6 disk space. The file servers use Areca 24-port SATA controller cards, and Western Digital WD4000YR disks. For a number of months we have been experiencing problems in which a disk would apparently drop from the array and then reappear a few seconds later, prompting a RAID array rebuild. In the end we sent one of our server boxes (approximately 80 kg, worth about 10kUSD) by express mail to Taiwan, and the Areca engineers looked at it more closely. (Many thanks to these engineers, who have given us first-rate support!) It turned out that our problems were due to a hardware problem with the WD4000YR drives. They have a SATA interface chip which (in some revisions of the WD4000YR) is incompatible with an interface chip used on the Areca RAID controller. This incompatibility is only triggered by issuing NCQ commands. So by disabling NCQ on the RAID controller, the problem was fixed. Our two remaining file servers have now been working without issues for more than two weeks.
These things were further exacerbated by my move to Germany with my family (our kids are 2.5 and 6 years old) which meant that I couldn't give these issues enough attention until now.
Hopefully these problems are behind us! I am grateful to everyone for their patience, and apologize for how long it took to track these things down and deal with them.
Cheers,
Bruce Allen
1)Projekt měl problémy s výkonem. Z důvodu přetížené databáze. Ta zpracovávala v průměru 950 žádostí za sekundu, nárazově až 3000.
Zapříčinil to způsob jakým pracuje BOINC scheduler a faktem, že při zpracování nové není mnoho jednotek s nízkou frekvenci. EAH je jediný projektem používajícím "locality scheduler" (jak to rozumně přeložít "místní scheduler" ) disajnovaný na rozesílání mnoha WU z jednoho datového souboru. Odesílá nový datový soubor jen když nezbývá žádná práce z předchozího. Co se stalo: Mnoho pomalých PC s soubory dat z malých frekvencí (jejich zpracování je rychlejší) žádalo práci pro tyto data. I když veškerá tato práce došla scheduler se jí snažil dál úporně hledat. Při prolézání celé databáze způsobilo její extrémní přetížení. 20% pomalých PC tedy generovalo obrovské množství přístupů do databáze při hledání neexistujících jednotek s nízkou frekvencí. Opravil jsem to (Bruce) pozměněním algoritmu na vyhledávání nové práce. Každý kdo se o to zajímá může se podívat příští týden na BOINC CVS.kdy zkontrolují upravený kód.
Zatížení databáze je nyní 60-80 žádostí za sekundu. Databázové servery a servery projektu jsou opět přístupné
2) Problém s file serverem. EAH využívá tři file servery, každý s kapacitou 8 TB diskového prostoru v RAID-6. File server užívá 24-portový SATA řadič Areca a Western Digital WD4000YR disky. Po několik měsíců jsme měli problémy. Disk se odpojil z pole. Když se po několika sekundách znova připojil vyžadoval obnovu diskového pole. Nakonec jsme jeden ze serverů (vážící 80 Kg o ceně 10K$) poslali expres poštou na Taiwan, kde se inženýři z Areca na problém důkladně podívali. (díky inženýrům za jejich prvotřídní podporu) Problém byl v HW-rový s disky WD4000YR. Jejich čip SATA rozhraní není (u některých revizí) kompatibilní s řadiči Arcea. Nekompatibilita se projevuje jen při použití NCQ. Problém byl tedy vyřešen vypnutím NCQ. Zbylé servery již jedou 14 dní bez problému.