Проглядел. А забугорные форумы некрофилов нагло лжгут.
3D-замедлитель доехал. Минимальный апгрейд уже произведён.
1) Таки подтвердилось, некая НЕХ происходит с изображением (мерцание и затемнение) при любых нагрузках на вывод картинки — именно из-за просевших за 27 лет электролитов.
Надо бы на Trio64V2 и V+ тоже променьять.
2) Но не надо. Только сегодня понял, что не зря вытащил этого виржика, он-то Direct3D держит, а MPEG стандарта VCD что-то как-то вещде одинаково крутится. Хотя тут типа нет аппаратного ускорения для него. Вроде. Надо еще раз проглядеть спеки.
1) Таки подтвердилось, некая НЕХ происходит с изображением (мерцание и затемнение) при любых нагрузках на вывод картинки — именно из-за просевших за 27 лет электролитов.
Надо бы на Trio64V2 и V+ тоже променьять.
2) Но не надо. Только сегодня понял, что не зря вытащил этого виржика, он-то Direct3D держит, а MPEG стандарта VCD что-то как-то вещде одинаково крутится. Хотя тут типа нет аппаратного ускорения для него. Вроде. Надо еще раз проглядеть спеки.
Вот вообще никогда бы не подумал, шо для полноценной работы PII+Zida BX98 на нативной 9x-винде, пригодится именно этот ископаемый кусок видеокарты.
Оно конечно умеет карточки 3Dfx, но ценники на них теперь совсем пизданутые.
Да и на такие тоже. Когда-то за 100 рублей никому были не нужны, а теперь за +500.
А всякий 4x/8x новодел работает только в XP. И никто это так и не победил, судя по форумам за 20 лет.
Цветность 24бит...
Но зато полноценное 3D аж с DX8.
И это сейчас я нашел драйвера, а в нулевые их вообще не было.
Оно конечно умеет карточки 3Dfx, но ценники на них теперь совсем пизданутые.
Да и на такие тоже. Когда-то за 100 рублей никому были не нужны, а теперь за +500.
А всякий 4x/8x новодел работает только в XP. И никто это так и не победил, судя по форумам за 20 лет.
Цветность 24бит...
Но зато полноценное 3D аж с DX8.
И это сейчас я нашел драйвера, а в нулевые их вообще не было.
Это просто праздник какой-то. Вот тут значит у нас AWS вчерась полеживал... Я когда начал писать панель управления Peterhost.ru в мае 2002 года, я как бы писал её на обычном аккаунте шаред-хостинга. И когда в конце августа 2002 мы её выкатили в бой, то так значит оно и осталось. И в том или ином виде панель управления на обычном аккаунте хостинга (конечно уже с подпорками) дожила до 2005 года. Бесплатных тарифов мы не делали, а на все условно бесплатные просто денег подкидывали периодически. Не спрашивайте меня почему. У себя мы сразу сделали бесплатный реально тариф. Тупили. Ну и как-то в 2005 денег мы панельке подкинуть забыли и она выключила сама себя. А на неё завязана вся автоматика, весь биллинг, всё вообще. И включить я её штатным образом обратно не могу — потому что включалка выключена, база отцеплена и вот это всё. Такая вот легенда.
И какой у вас план, товарищ Жюков? (С)
"""
# riak-admin cluster plan
[...]
Status Ring Pending Node
-------------------------------------------------------------------------------
valid 5.9% 5.9% 'riak@192.168.0.130'
valid 6.3% 5.9% 'riak@192.168.0.131'
valid 5.5% 5.1% 'riak@192.168.0.132'
valid 5.5% 5.1% 'riak@192.168.0.133'
valid 5.5% 5.5% 'riak@192.168.0.134'
valid 5.5% 5.5% 'riak@192.168.0.135'
valid 5.5% 5.5% 'riak@192.168.0.136'
valid 5.5% 5.1% 'riak@192.168.0.137'
valid 5.5% 5.1% 'riak@192.168.0.138'
valid 5.5% 5.1% 'riak@192.168.0.139'
valid 5.5% 5.1% 'riak@192.168.0.140'
valid 5.9% 5.9% 'riak@192.168.0.141'
valid 5.5% 5.1% 'riak@192.168.0.142'
valid 5.5% 5.1% 'riak@192.168.0.143'
valid 5.5% 5.1% 'riak@192.168.0.144'
valid 5.5% 5.1% 'riak@192.168.0.145'
valid 5.5% 5.1% 'riak@192.168.0.146'
valid 5.5% 5.1% 'riak@192.168.0.147'
valid 0.0% 5.1% 'riak@192.168.0.148'
[...]
"""
План, блин, чистый термояд.
"""
# riak-admin cluster plan
[...]
Status Ring Pending Node
-------------------------------------------------------------------------------
valid 5.9% 5.9% 'riak@192.168.0.130'
valid 6.3% 5.9% 'riak@192.168.0.131'
valid 5.5% 5.1% 'riak@192.168.0.132'
valid 5.5% 5.1% 'riak@192.168.0.133'
valid 5.5% 5.5% 'riak@192.168.0.134'
valid 5.5% 5.5% 'riak@192.168.0.135'
valid 5.5% 5.5% 'riak@192.168.0.136'
valid 5.5% 5.1% 'riak@192.168.0.137'
valid 5.5% 5.1% 'riak@192.168.0.138'
valid 5.5% 5.1% 'riak@192.168.0.139'
valid 5.5% 5.1% 'riak@192.168.0.140'
valid 5.9% 5.9% 'riak@192.168.0.141'
valid 5.5% 5.1% 'riak@192.168.0.142'
valid 5.5% 5.1% 'riak@192.168.0.143'
valid 5.5% 5.1% 'riak@192.168.0.144'
valid 5.5% 5.1% 'riak@192.168.0.145'
valid 5.5% 5.1% 'riak@192.168.0.146'
valid 5.5% 5.1% 'riak@192.168.0.147'
valid 0.0% 5.1% 'riak@192.168.0.148'
[...]
"""
План, блин, чистый термояд.
Удалили 4Тб данных из s3. Логически их не видно. А по факту — удаление из БД riak производится примерно по десятку блоков в секунду. Один блок — в пределах 15Мб, если правильно помню.
Вобщем, это надолго...
Вобщем, это надолго...
Прирост общего объёма за месяц — с 19.3Тб до 21.9Тб
Однако, надо что-то делать, иначе местов не хватит.
Однако, надо что-то делать, иначе местов не хватит.
in case of quick backup needed
Write-S3Object -BucketName backup-backet -File D:\backup.zip -Key /backups/backup-0.zip
Copy-S3Object -BucketName backupbacket -LocalFile d:\backup.zip -Key /backups/backup-0.zip
Нашел, почему riak может падать, выражаясь про "нашу базу уже кто-то юзает!"
При большой нагрузке на диск при попытке открыть файл БД делается попытка залочить. Спустя N секунд записать в файл лока не получается (нагрузка всё ж великовата) — ругаемся и выключаемся.
При большой нагрузке на диск при попытке открыть файл БД делается попытка залочить. Спустя N секунд записать в файл лока не получается (нагрузка всё ж великовата) — ругаемся и выключаемся.
Жуйка, подскажи, что лучше GridFS vs S3. Вот сижу и думаю, что будет лучше. Засунуть все свои файлы в ГридФС Монги и заморочиться с амазоновским С3.
GridFS выглядит няшно, репликации, шардинг, относительно секурно. Мне часть файлов нельзя напрямки отдавать.
S3 привлекает простой хранения и масштабирования.
Задача — хранить миллионы mp3-шек и документов.
Я тут еще на Swift смотрел, но мутное оно какое-то.
GridFS выглядит няшно, репликации, шардинг, относительно секурно. Мне часть файлов нельзя напрямки отдавать.
S3 привлекает простой хранения и масштабирования.
Задача — хранить миллионы mp3-шек и документов.
Я тут еще на Swift смотрел, но мутное оно какое-то.
Клиент хотел сэкономить и делал бекапы в S3. Согласен, 3 руб/Гб в месяц дешевле 5 руб/Гб.
Но есть одно но! У товарища глюкнул duply, который настраивал он, и не удалил старые файлы.
В результате за месяц вышло примерно так же, как в случае штатного резервного копирования, но с возможными проблемами при восстановлении данных (с учётом глюков — вероятность проблем повышается).
Но есть одно но! У товарища глюкнул duply, который настраивал он, и не удалил старые файлы.
В результате за месяц вышло примерно так же, как в случае штатного резервного копирования, но с возможными проблемами при восстановлении данных (с учётом глюков — вероятность проблем повышается).
Таки покормили кластер риак железом. Переваривает.
Риак начал страдать падучей, а железо будет только на следующей неделе...
Однако, хреново.
Пока пытаюсь обходиться мелким тюнингом типа bitcask.max_merge_size = 50GB
Однако, хреново.
Пока пытаюсь обходиться мелким тюнингом типа bitcask.max_merge_size = 50GB
riak зачихал в очередной раз.
Вначале он упал одним из узлов. Причина — "а хто-то тут ещё кроме меня файлы БД юзает!"
Поднял. Через полчаса посмотрел, что как — трансфер разделов висит.
Перепнул (штатно!) оба узла, участвовавшие в трансфере — один из узлов начал сыпать ошибками "файл повреждён".
Вот какого хрена оно повреждает при штатном рестарте?! Ладно, это не файл БД, можно прибить.
Теперь перестали отдавать крупные файлы.
Помог только животворящий пинок в кластер (в смысле, перезапустил вообще все узлы по-очереди).
Чёрт знает что... Жду железа, а то его кормить нечем... Да и на ceph стоило бы переехать...
Вначале он упал одним из узлов. Причина — "а хто-то тут ещё кроме меня файлы БД юзает!"
Поднял. Через полчаса посмотрел, что как — трансфер разделов висит.
Перепнул (штатно!) оба узла, участвовавшие в трансфере — один из узлов начал сыпать ошибками "файл повреждён".
Вот какого хрена оно повреждает при штатном рестарте?! Ладно, это не файл БД, можно прибить.
Теперь перестали отдавать крупные файлы.
Помог только животворящий пинок в кластер (в смысле, перезапустил вообще все узлы по-очереди).
Чёрт знает что... Жду железа, а то его кормить нечем... Да и на ceph стоило бы переехать...
Чихающий s3, который недокормили железом, почему-то за последний месяц пользуется ахренительной популярностью.
У нас что, где-то резко подскочили цены на хранилища?
У нас что, где-то резко подскочили цены на хранилища?
Обнаружил файл, который невозможно получить из хранилища, для которого невозможно узнать подробную информацию (права доступа и т.п.), но который видно на листинге бакета.
Хочу riak-cs-fsck...
Хочу riak-cs-fsck...
Риак — странная штука. Вот например, как он планирует распределить место в кластере после добавления ещё одного узла:
Status Ring Pending Node
-------------------------------------------------------------------------------
valid 8.6% 8.6% 'riak@192.168.0.130'
valid 8.2% 7.8% 'riak@192.168.0.131'
valid 8.2% 7.4% 'riak@192.168.0.132'
valid 8.2% 7.4% 'riak@192.168.0.133'
valid 8.2% 7.4% 'riak@192.168.0.134'
valid 8.2% 7.4% 'riak@192.168.0.135'
valid 8.2% 7.4% 'riak@192.168.0.136'
valid 8.2% 7.4% 'riak@192.168.0.137'
valid 8.2% 7.4% 'riak@192.168.0.138'
valid 8.2% 7.4% 'riak@192.168.0.139'
valid 8.2% 7.4% 'riak@192.168.0.140'
valid 9.4% 9.4% 'riak@192.168.0.141'
valid 0.0% 7.4% 'riak@192.168.0.142'
-------------------------------------------------------------------------------
Valid:13 Leaving:0 Exiting:0 Joining:0 Down:0
Обратите внимание на то, что у .141 как был самый большой процент, так и остался.
Status Ring Pending Node
-------------------------------------------------------------------------------
valid 8.6% 8.6% 'riak@192.168.0.130'
valid 8.2% 7.8% 'riak@192.168.0.131'
valid 8.2% 7.4% 'riak@192.168.0.132'
valid 8.2% 7.4% 'riak@192.168.0.133'
valid 8.2% 7.4% 'riak@192.168.0.134'
valid 8.2% 7.4% 'riak@192.168.0.135'
valid 8.2% 7.4% 'riak@192.168.0.136'
valid 8.2% 7.4% 'riak@192.168.0.137'
valid 8.2% 7.4% 'riak@192.168.0.138'
valid 8.2% 7.4% 'riak@192.168.0.139'
valid 8.2% 7.4% 'riak@192.168.0.140'
valid 9.4% 9.4% 'riak@192.168.0.141'
valid 0.0% 7.4% 'riak@192.168.0.142'
-------------------------------------------------------------------------------
Valid:13 Leaving:0 Exiting:0 Joining:0 Down:0
Обратите внимание на то, что у .141 как был самый большой процент, так и остался.
Для того, чтобы riak нормально работал, его периодически (где-то ближе к 70% заполнения диска на узлах) надо подкармливать серверами.
Из общения с продаваном riak:
"""
We have customers putting petabytes of data in CS and not using raid, so it would be interesting to hear what your reasons for using raid are? As Raid is complex to use.
"""
Вот только на raid мы перешли как раз после потери данных
"""
We have customers putting petabytes of data in CS and not using raid, so it would be interesting to hear what your reasons for using raid are? As Raid is complex to use.
"""
Вот только на raid мы перешли как раз после потери данных
Наблюдаю в логах riak надписи вида:
2016-02-15 09:22:07.687 [info] <0.4996.18> Merged {["/var/lib/riak/bitcask/28544953854119197621165719388989902727654932480/304.bitcask.data", ...... ,[]} in 637.526956 seconds.
При этом занятое место на диске только увеличивается. Интересно, оно совсем всё сожрёт или всё ж откатит по окончании всех мержей?
2016-02-15 09:22:07.687 [info] <0.4996.18> Merged {["/var/lib/riak/bitcask/28544953854119197621165719388989902727654932480/304.bitcask.data", ...... ,[]} in 637.526956 seconds.
При этом занятое место на диске только увеличивается. Интересно, оно совсем всё сожрёт или всё ж откатит по окончании всех мержей?
В процессе повторного расширения ceph (после тестов на накрытие одного из узлов) наблюдаю:
102/2499186 objects degraded (0.004%); 766347/2499186 objects misplaced (30.664%);
При этом первое соотношение не меняется, в отличие от второго. По-моему, должно быть наоборот, так как degraded — это когда есть только одна копия и это хуже, чем когда одна из копий misplaced.
Надо поискать ручки для кручения приоритетов на сей предмет.
102/2499186 objects degraded (0.004%); 766347/2499186 objects misplaced (30.664%);
При этом первое соотношение не меняется, в отличие от второго. По-моему, должно быть наоборот, так как degraded — это когда есть только одна копия и это хуже, чем когда одна из копий misplaced.
Надо поискать ручки для кручения приоритетов на сей предмет.
Как и riak, ceph требует пинка при падении одного из узлов. Это нормально, везде так.
Но что мне нравится, так это перебалансировка кластера после того, как указал ему, что того узла больше нет и не будет.
Упирается в лимит по iops на вдс И при этом скорость работы с контентом меняется незначительно по сравнению с riak (на больших файлах — нет разницы с обычной работой, на мелких — деградация где-то полтора раза, причём во время работы клиентов скорость перебалансировки заметно снижается, то есть приоритет — у клиентов)
Но что мне нравится, так это перебалансировка кластера после того, как указал ему, что того узла больше нет и не будет.
Упирается в лимит по iops на вдс И при этом скорость работы с контентом меняется незначительно по сравнению с riak (на больших файлах — нет разницы с обычной работой, на мелких — деградация где-то полтора раза, причём во время работы клиентов скорость перебалансировки заметно снижается, то есть приоритет — у клиентов)
Скорость ответа ceph по s3 в момент, когда он в состянии "так, давайте-ка шустренько распределим полкластера по новым серверам", примерно соответствует скорости ответа riak-cs/riak в момент, когда туда лезет ровно один клиент и в кластере больше вообще ничего не происходит.
После письма в рассылку с конкретной проблемой riak в почту постучался продаван этого самого риака на предмет платной техподдержки.
Я всё понимаю, судя по объёмам данных клиент крупный и т.п. Но, блин, оно ж себя и так-то еле окупает (сопутствующий сервис), а тут вообще будет убыточным.
Я всё понимаю, судя по объёмам данных клиент крупный и т.п. Но, блин, оно ж себя и так-то еле окупает (сопутствующий сервис), а тут вообще будет убыточным.
Выяснил, что в s3 от ceph можно создать пользователей с заданными ключами.
Чтож, не понадобится править фронтенд.
Чтож, не понадобится править фронтенд.
Краткое сравнение возможностей настройки riak+riak-cs, sx+libres3 и ceph с его rados gw:
* sx — никаких ручек для настройки, кроме как задать, сколько места можно отожрать на конкретном узле.
* riak+riak-cs — ручек для настройки много, но бОльшая часть спрятана и недокументирована. Правда, для того, чтоб загрузить терабайт хрени в кластер оно не шибко надо. Шибко надо оно, чтоб в этом терабайте был миллион-другой файлов в одном бакете...
* ceph — ручек для настройки дохрена. И все надо настраивать, иначе даже для теста получится некая хрень...
* sx — никаких ручек для настройки, кроме как задать, сколько места можно отожрать на конкретном узле.
* riak+riak-cs — ручек для настройки много, но бОльшая часть спрятана и недокументирована. Правда, для того, чтоб загрузить терабайт хрени в кластер оно не шибко надо. Шибко надо оно, чтоб в этом терабайте был миллион-другой файлов в одном бакете...
* ceph — ручек для настройки дохрена. И все надо настраивать, иначе даже для теста получится некая хрень...
Один из допсерверов таки вошел в кластер. Осталось ещё два.
Запихивать их разом — не рискну, чревато резкой просадкой производительности вплоть до недоступности кластера по таймауту.
Запихивать их разом — не рискну, чревато резкой просадкой производительности вплоть до недоступности кластера по таймауту.
Пишу веб-морду к s3 для хранения фоточек. Возник вопрос: стоит ли делать thumbnails для оных? С одной стороны — экономия трафика, но с другой — дополнительный расход места. Но трафик стоит ~ $0.09/GB, при этом первый GB/мес — бесплатно... А место стоит ~ $0.03/GB. Так нужны эти тамбнейлс или нет?
В одном из бакетов дофига файлов (несколько миллионов).
Но таки требуется получить список, дабы пройтись по нему и синхронизировать с другим хранилищем.
Вопрос: как получить список, если s3cmd тупо падает?
Но таки требуется получить список, дабы пройтись по нему и синхронизировать с другим хранилищем.
Вопрос: как получить список, если s3cmd тупо падает?
Наступил на тестовом кластере на баг с потерей данных.
Баг закрыли, но осталось дофига бакетов, которые видно по s3cmd ls, но на s3cmd ls s3://bucket выдаёт ошибку.
Ладно, раз их тупо нет в списке бакетов, взятом через э... отладку, то запись о сих бакетах прибили.
Пересоздал бакеты. Делаю s3cmd ls s3://bucket — а там файлО лежит, какое лежало.
Баг закрыли, но осталось дофига бакетов, которые видно по s3cmd ls, но на s3cmd ls s3://bucket выдаёт ошибку.
Ладно, раз их тупо нет в списке бакетов, взятом через э... отладку, то запись о сих бакетах прибили.
Пересоздал бакеты. Делаю s3cmd ls s3://bucket — а там файлО лежит, какое лежало.
Эй, жуйк, а кто-нибудь юзает s3 как личное хранилище: фоточки, там, и прочее?
раз тут везде bucket'ы — слушаю buckethead
Запись в логе:
@riak_core:wait_for_service:470 Waiting for service riak_kv to start (8580 seconds)
riak_kv — основной сервис узла.
При этом узел работает, отвечает на запросы от riak-cs и соседей.
Надо будет вечером посмотреть, к полуночи запустится или нет.
@riak_core:wait_for_service:470 Waiting for service riak_kv to start (8580 seconds)
riak_kv — основной сервис узла.
При этом узел работает, отвечает на запросы от riak-cs и соседей.
Надо будет вечером посмотреть, к полуночи запустится или нет.
$ time s3curl.pl --id admin — -s s3.domain.tld > USERS; echo $?
real 1m9.942s
user 0m0.040s
sys 0m0.012s
0
$ time s3curl.pl --id admin — -s s3.domain.tld > USERS2; echo $?
real 1m2.109s
user 0m0.044s
sys 0m0.008s
0
$ ls -l USERS*
-rw-r--r-- 1 stas stas 102545 Апр 6 18:10 USERS
-rw-r--r-- 1 stas stas 191666 Апр 6 18:13 USERS2
Очень интересует, как сформулировать письмо в рассылку без мата...
real 1m9.942s
user 0m0.040s
sys 0m0.012s
0
$ time s3curl.pl --id admin — -s s3.domain.tld > USERS2; echo $?
real 1m2.109s
user 0m0.044s
sys 0m0.008s
0
$ ls -l USERS*
-rw-r--r-- 1 stas stas 102545 Апр 6 18:10 USERS
-rw-r--r-- 1 stas stas 191666 Апр 6 18:13 USERS2
Очень интересует, как сформулировать письмо в рассылку без мата...
Плюнули на рассылку, решили разгрузить кластер по юзерским запросам.
Соорудили кеш для анонимных GET на базе nginx и типа-redis.
Типа-redis потому типа, что он базу хранит на диске, а не в памяти.
Но интерфейс — таки redis.
Соорудили кеш для анонимных GET на базе nginx и типа-redis.
Типа-redis потому типа, что он базу хранит на диске, а не в памяти.
Но интерфейс — таки redis.
Очень хочется сломать. Вместе с железками.
Эта сволочь после расширения кластера стала работать медленнее.
Эта сволочь после расширения кластера стала работать медленнее.
"Случайно" выключили клиента на 20 секунд. Трафик за эти 20 секунд упал в 20 раз.
Ну чо... Еще пару таких клиентов бы...
Ну чо... Еще пару таких клиентов бы...
В s3 основную нагрузку создаёт единственный клиент, который там хранить несколько миллионов картинок ради отдачи их со своего сайта.
По объёму он далеко не первый, но зато из ~2000 запросов в секунду сейчас, 1900 — его.
По объёму он далеко не первый, но зато из ~2000 запросов в секунду сейчас, 1900 — его.
Прям про мою работу: #2750822