1

(13 odpowiedzi, napisanych Oprogramowanie / Software)

Ja też miałem problem z DNSami i gdzieś przeczytałem pomysł żeby przeformatować. Problem ustąpił (format z poziomu routera) a teraz czytając ten temat skumałem, że wcześniej faktycznie formatowałem pod Ubuntu. Tak więc jestem kolejnym potwierdzeniem :-)

2

(13 odpowiedzi, napisanych Oprogramowanie / Software)

Ktoś się orientuje czemu dokładnie tak jest? Co jest specjalnego w formatowaniu pod Ubuntu?

Ma podobne objawy z Transmission 2.72 z ostatniego Gargoyle, już tak wyklinam na nie że masakra.
W porównaniu do jakiejś stareńkiej wersji której używałem wcześniej (chyba 2.12?) obecna cechuje się bardzo ale to bardzo wysokim użyciem CPU podczas ściągania. Gdy seeduje jest około 0.10.

Wynik uptime po ok. 30 min. ściągania (tylko ściągania)

 21:20:58 up 23:33,  load average: 4.15, 3.16, 2.96

przy czym jak obserwuję htop to jest ciągła czkawka pomiędzy 20-95% zależnie od tego ile z kilku uruchomionych procesów transmission jedzie akurat po maksie (każdy z nich pokazuje od ok. 5% do ok. 30%, jak kilka na raz jest na 30% to jest kicha)

Router podczas ściągania muli bardzo, więc faktycznie obciążenie CPU jest znaczne, do tego stopnia że się router potrafi zrestartować.
No i po upgrade zauważyłem że co zajrzę na router to nie działa transmission choć głowę daję że zostawiałem włączone. Dodałem do crona wywołanie testu co parę minut:

if ! ps | grep trans | grep mission > /dev/null ; then
  /etc/init.d/transmission start
  timestamp=`date +"%Y.%m.%d-%H:%M:%S"`
  echo $timestamp " started transmission" >> ~/transtarts.log
fi

Czyli sprawdzenie czy działa, i jak nie działa to restart + wpis do księgi pamiątkowej. No i okazuje się że jak seeduję to restartów transmission nie ma, a jak ściągam to są. To się pokrywa z obciążeniem procka, więc podejrzewając zbyt dużą ilość połączeń zacząłem dłubać przy ustawieniach. Obecnie zszedłem do następującego stanu:

config transmission
        option alt_speed_down '150'
        option alt_speed_up '20'
...
        option download_queue_size '4'
        option encryption '1'
        option idle_seeding_limit '15'
        option idle_seeding_limit_enabled 'false'
...
        option peer_limit_global '12'
        option peer_limit_per_torrent '4'
        option speed_limit_down '1000'
        option speed_limit_up '70'

I dalej jest koszmarnie, przy ograniczeniu do klikunastu połączeń! Nieco lepiej w trybie "żółwia" ale ciągle koszmarnie.

Teraz nie wiem czy jest to problem nowego Transmission (jest sporo w googlach pod hasłem transmission high CPU load, ale zwykle chodzi o wersję desktop) czy problem TPLinka 1043.

Ma ktoś podobne akcje? Udało się wam przywrócić normalne działanie?

Cezary napisał/a:

sdparm --set SCT=36000 -6 /dev/sda Usypianie po godzinie
sdparm --set SCT=600 -6 /dev/sda Usypianie po minucie.

Cezary czy używasz przełącznika -6 dla kompatybilności? Czytałem że to wymusza 6-bajtowy tryb komend, ale czy można przyjąć za regułę że 6-bajtowy działa zawsze, a domyślny 10-bajtowy może czasami nie zadziałać?