GE вопросы, скорость выхода

Гигабит, но сторж максимум 60 мбит выдает в пиках. Выход сателита на 63гб за сутки всего 10%! Это смешно как-то, я думал сторж сможет выжать 500-800Мбит/с

Он может и больше. А вот GE видимо медленная штука.
Я напишу разработчикам.

Может попробуем увеличить количество параллельных потоков? Раз канал всё равно пустой

Думаю такое количество должно забивать канал, но увы.

# number of concurrent transfers per graceful exit worker
graceful-exit.num-concurrent-transfers: 200

# number of workers to handle satellite exits
graceful-exit.num-workers: 200

И какой трафик выходит (стефан в обычном режиме) +/- 8 гб в за сутки вышло.
image
Процессор ~15-20% от одного ядра E3-1275v6, диск

DSK | sda | busy 1% | read 7 | write 222 | KiB/r 316 | KiB/w 6 | MBr/s 0.2 | MBw/s 0.2 | avq 4.15 | avio 0.58 ms |

Мой Node ID: 12kSz4gY5YDXAS8ZzPmZpczzV5C2kus7E8nuKiwm5eDb8W9CjKo

@Alexey and @littleskunk. The satellite seems to be blocking the exit. My node reaches a download speed of 400 Mbit + for 3-4 seconds, and then, for no apparent reason, the speed drops. No, this is not a disk problem. For the test, I put all the files in RAM and the base too;)
Tested workers count 1-1000 and parallel uploads 1-200 per woker.

9 Likes

Done! Only 4 days to upload 63 gib via 1gbit connection. super fast v3 on par with AWS :rofl:

2 Likes

We are deploying v0.30.5 on Stefans satellite in a minute. By default the satellite will send 100 graceful exit orders per request. On Stefans satellite increased that to be 1000. Please keep an eye on your storage nodes.

Please be careful with increase the batch size on the storage node side. 100 parallel transfers should still work. I would recommend a lower value. Basically take the lowest values that will max out your connection. If you target for too many parallel transfers some of them might fail. Remember that we do have a penalty in place for that. Be careful playing around with the options.

After the first attempt, I saw that none of the combinations allowed me to achieve a normal load on the channel. Even 100 parallel threads given that all the pieces and bases are in RAM. So 100 orders is critical low value. I would like to see a queue of up to 10,000 pieces and automatically add to the list when 4000-6000 pieces are passed out of 10,000

That is too high for now. We don’t want to disqualify slow storage nodes just because they can’t transfer 10.000 pieces before the graceful exit order is getting too old.

Yes please. I can point you to the place where this feature would have to be added. At the moment I don’t think I can convice the developer team implementing it because of priorities. If someone from the community wants to take it I am happy to help.

После обновления сателлита, много ошибок

to this ip i got many failures too

Doest sattelite give node ip to what transfer piece, or it give node list for each piece where can node tranfer?

А как загрузка процессора может быть выше 100%? Или в этом мониторинге за 100% принимается полная загрузка только одного ядра/потока? А 200% соответвенно 2 потока из 6 загружено?

Аудиты же это копеечный трафик. Что-то около 500 байт на 1 аудит. Которых всего по несколько штук в день с каждого из спутников приходит. Т.е. несколько десятков КБ трафика в сутки суммарно. О каких лимитах по трафику тут смысл говорить?

Зачем вообще нужны лимиты по трафику - понятно и это вещь полезная. Но если пользователь не подумал и не задал этот лимит с запасом хотя бы в 1 ГБ или больше, то его экономия неск. десятков КБ или пусть даже 1 МБ в сутки не спасет. Служебный фоновый трафик, который не слушает никаких лимитов больше съедает и он все-равно вылетит за лимит провайдера. Те же “пинги” при проверке онлайна, которых намного больше чем аудитов сыпется или пересылка телеметрии или постоянные (по умолчанию каждые 15 минут) проверки новой версии ПО обновлялкой и т.д… Не говоря уже о трафике от другого ПО испозющегося на том же копьютере/том же подключении.
А если и их все отлючать и полностью рубить весь трафик, то с таким успехом можно сразу дисквалифицировать любую ноду сразу же по достижении лимита по трафику - все равно она через какое-то время завалится из-за провала аудитов и проверок по аптайму.

После последних обновлений стало намного лучше. Нагрузка упала, скорость отдачи выросла.

1 Like

На недельном графике заметна разница

1 Like

Почему запрашиваются аудиты сателлитом, если он уже закончил GE


@makarich Can you post the log message that shows when the piece with ID P7D…QOA was transferred by the graceful exit?

2020-02-01T19:01:07.076Z        ERROR   gracefulexit:chore      failed to put piece.    {"Satellite ID": "12EayRS2V1kEsWESU9QMRseFhdxYxKicsiFmxrsLZHeLUtdps3S", "Piece ID": "P7D2ORSKNDHF3FCNPNWB3GDFCGCFQTWFBJVURNGJXCLPKYNSJQOA", "error": "protocol: storage node overloaded", "errorVerbose": "protocol: storage node overloaded\n\tstorj.io/uplink/piecestore.(*Upload).Write:160\n\tbufio.(*Writer).Flush:593\n\tbufio.(*Writer).Write:629\n\tstorj.io/uplink/piecestore.(*BufferedUpload).Write:32\n\tstorj.io/uplink/piecestore.(*LockingUpload).Write:89\n\tio.copyBuffer:404\n\tio.Copy:364\n\tstorj.io/common/sync2.Copy:22\n\tstorj.io/uplink/ecclient.(*ecClient).PutPiece:240\n\tstorj.io/storj/storagenode/gracefulexit.(*Worker).transferPiece:213\n\tstorj.io/storj/storagenode/gracefulexit.(*Worker).Run.func2:111\n\tstorj.io/common/sync2.(*Limiter).Go.func1:41"}

2020-02-01T19:01:36.420Z ERROR gracefulexit:chore failed to put piece. {“Satellite ID”: “12EayRS2V1kEsWESU9QMRseFhdxYxKicsiFmxrsLZHeLUtdps3S”, “Piece ID”: “P7D2ORSKNDHF3FCNPNWB3GDFCGCFQTWFBJVURNGJXCLPKYNSJQOA”, “error”: “protocol: expected piece hash; usedserialsdb error: database is locked”, “errorVerbose”: “protocol: expected piece hash; usedserialsdb error: database is locked\n\tstorj.io/storj/storagenode/gracefulexit.(*Worker).transferPiece:225\n\tstorj.io/storj/storagenode/gracefulexit.(*Worker).Run.func2:111\n\tstorj.io/common/sync2.(*Limiter).Go.func1:41”}

Thanks @makarich! These logs are about an unsuccessful attempt for transferring that piece. Unsuccessful transfers does not result in deleting the piece on the exiting node.

Could you find a log for a successful transfer for that piece?