Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
Strony: 1
Orientuje się ktoś z jakiego powodu może się powiesić system przy tworzeniu pliku z /dev/zero ? Kernel odpowiada bo można zresetować pc przez sysrq ale po wydaniu
dd if=/dev/zero of=./plik bs=1M count=1000
system w pewnych warunkach pada martwy i nie idzie go dobudzić w żaden sposób.
Ostatnio edytowany przez morfik (2014-01-03 20:36:47)
Offline
Inne jajo.
System może sobie w ten sposób zapchać dyzia, ale nie powinien się zamrażać.
Chyba, że zamarzanie ma swój powód w 100% obciążeniu procka (pomocne mogą być cpulimit, cgroup_cpu), albo zablokowania dyzia przez wyczerpanie limitu operacji IO.
W takim przypadku można pobawić się programikiem ionice albo cgroup_blkio.
Offline
To chyba jednak nie jest problem wykorzystania zasobów.
Zrobiłem sobie taką regułkę:
group users/dd { perm { task { uid = root; gid = root; } admin { uid = root; gid = root; } } blkio { blkio.throttle.write_bps_device = "8:0 5242880"; blkio.throttle.read_bps_device = "8:0 5242880"; } }
8:0 to jest mój główny dysk, a ten 5242880 to 5M zapisu/odczytu max. Podpiąłem to pod dd
*:dd blkio users/dd/ *:dd* blkio users/dd/
i w logu cgrulesengd można przeczytać:
Found matching rule * for PID: 28946, UID: 1000, GID: 1000 Executing rule * for PID 28946... Will move pid 28946 to cgroup 'users/dd/' Adding controller blkio OK! Cgroup change for PID: 28946, UID: 1000, GID: 1000, PROCNAME: /bin/dd OK
A pid widnieje w /cgroup/blkio/users/dd/tasks -- także chyba to działa dobrze. Problem w tym, że to wcale nie ogranicza niczego. :]
$ dd if=/dev/zero of=./zero bs=1M ^C3502+0 records in 3502+0 records out 3672113152 bytes (3.7 GB) copied, 40.466 s, 90.7 MB/s $ dd if=/dev/zero of=./zero bs=1M ^C601+0 records in 601+0 records out 630194176 bytes (630 MB) copied, 8.5338 s, 73.8 MB/s
Znów coś ff jest zamieszany, bo to wieszanie się systemu przy używaniu dd, występuje najczęściej gdy ff jest odpalony.
Offline
Cgroup nie zakłada sztywnych ograniczeń na procek i dysk (tylko w memory można nakładać sztywne limity), zapewnia natomiast, że w czasie maksymalnego obciążenia dany proces będzie trzymany w danym limicie, wylicznym średnią ważoną.
Np w cpu:
Proces 1 - 500
proces 2 - 1000
Przy niskim obciążeniu każdy proces może zająć praktycznie cały procek, ale przy pełnym wykorzystaniu procka dostaną te procesy 1 - 33%, 2 - 66% mocy procka.
To jest dynamiczny podział.
U Ciebie wyraźnie dyzio się nie wyrabia.
Offline
Z czym nie wyrabia? Z kopiowaniem pliku?
To co powyżej było ten 90.7 MB/s przeszedł swobodnie, natomiast pc się przyciął przy 2-5MB/s udało mi się to zobaczyć po paru minutach wciskania ctrl+c. W końcu ubiło proces i wyrzuciło staty dd. Także tutaj coś innego ma znaczenie. Nie wiem co ale jak to dorwę to pewnie rozwiąże wszystkie problemy.
Narazie spróbuję zrobić sobie kopię systemu i wrzucić ja do pliku img i wypalić na drugim dysku, niezaszyfrowanym. Być może tutaj coś jest nie tak z szyfrowaniem.
Offline
Ten problem również został rozwiązany przez dodanie:
echo $((16*1024*1024)) > /proc/sys/vm/dirty_background_bytes echo $((48*1024*1024)) > /proc/sys/vm/dirty_bytes
Więcej info na http://lwn.net/Articles/572911/
Offline
Strony: 1
Time (s) | Query |
---|---|
0.00009 | SET CHARSET latin2 |
0.00004 | SET NAMES latin2 |
0.00102 | SELECT u.*, g.*, o.logged FROM punbb_users AS u INNER JOIN punbb_groups AS g ON u.group_id=g.g_id LEFT JOIN punbb_online AS o ON o.ident='3.148.108.144' WHERE u.id=1 |
0.00097 | REPLACE INTO punbb_online (user_id, ident, logged) VALUES(1, '3.148.108.144', 1732381866) |
0.00041 | SELECT * FROM punbb_online WHERE logged<1732381566 |
0.00078 | DELETE FROM punbb_online WHERE ident='3.135.214.175' |
0.00091 | DELETE FROM punbb_online WHERE ident='3.145.109.144' |
0.00091 | DELETE FROM punbb_online WHERE ident='3.148.108.201' |
0.00072 | SELECT topic_id FROM punbb_posts WHERE id=249754 |
0.00006 | SELECT id FROM punbb_posts WHERE topic_id=24906 ORDER BY posted |
0.00058 | SELECT t.subject, t.closed, t.num_replies, t.sticky, f.id AS forum_id, f.forum_name, f.moderators, fp.post_replies, 0 FROM punbb_topics AS t INNER JOIN punbb_forums AS f ON f.id=t.forum_id LEFT JOIN punbb_forum_perms AS fp ON (fp.forum_id=f.id AND fp.group_id=3) WHERE (fp.read_forum IS NULL OR fp.read_forum=1) AND t.id=24906 AND t.moved_to IS NULL |
0.00014 | SELECT search_for, replace_with FROM punbb_censoring |
0.00173 | SELECT u.email, u.title, u.url, u.location, u.use_avatar, u.signature, u.email_setting, u.num_posts, u.registered, u.admin_note, p.id, p.poster AS username, p.poster_id, p.poster_ip, p.poster_email, p.message, p.hide_smilies, p.posted, p.edited, p.edited_by, g.g_id, g.g_user_title, o.user_id AS is_online FROM punbb_posts AS p INNER JOIN punbb_users AS u ON u.id=p.poster_id INNER JOIN punbb_groups AS g ON g.g_id=u.group_id LEFT JOIN punbb_online AS o ON (o.user_id=u.id AND o.user_id!=1 AND o.idle=0) WHERE p.topic_id=24906 ORDER BY p.id LIMIT 0,25 |
0.00108 | UPDATE punbb_topics SET num_views=num_views+1 WHERE id=24906 |
Total query time: 0.00944 s |