Изпечатай

[R4]

Здравейте,
много малко успях да прочета за това, което искам да направя и може да получа отговори тип "RTFM", но все пак и те са добре дошли (стига да има линк към тях  '> ). Наистина!

Всичко започна от следният факт: прехвърлям филм от машина с Win2k на друга машина с Win2k и меря трансфера на данни с няколко програми от типа DU Meter и BW Meter. Трансфера варира между 6 и 7Мб/сек, а времето е около 2мин.

Наскоро в тази мрежа (домашна мрежичка е) сложих на рутера (Slack9.1) един голям харддиск и пуснах Самба. Въпросът е, че не мога да постигна тези резултати. Достигам максимум 4,5Мб/сек, като натоварването на самата машина е около 65%, почти изцяло от Самбата.

Ясно е, че всичко е относително. Все пак до колкото мога да направя сметка една 100 мегабитова мрежа има максимална лента на пропускане от 12,5Мб/сек. Не очаквам да получа такъв трансфер с моя хардуер (суичове и кабели), но съм постигал, както казах, 7Мб/сек.

Машината ми е AMD K6 266Mhz, ядрото е 2.4.26 прекомпилирано за процесора. Лан картата, на която работи Самбата е Intel 82559. Ползвам eepro100 модула. Файловата ситема е XFS, RAM 128Mb, харддиска е Baracuda 7200.7 80Gb. За съжаление BIOS-а не го разпознава и съм сложил един RAID контролер, който ползвам само като IDE. Той e SiI и работи с модула CMD649. Ползвам Самба 3.0.4, която съм взел като пакет от Слак10.0.

Това е! Какво мислите? Има ли начин да изкарам нещо повече от това, което имам в момента.

Ето още нещо, което се сетих:
hdparm -tT /dev/hde

/dev/hde:
 Timing buffer-cache reads:   128 MB in  3.56 seconds = 35.96 MB/sec
 Timing buffered disk reads:  64 MB in  5.25 seconds = 12.19 MB/sec

[Nerf]

Здрасти

Предполагам PC-та с Win2K са с доста по-добър хардуер от smb сървъра. Такаче е логично да са по-бързи.
Аз също имам едо PC K6 266MHz и на него немога да постигна по голям трансвер от 4-5MB/s  дори и през FTP. Според мен просто хардуера няма да ти позволи повече.
Но ако имаш желание даи да видим smb.conf

[nix]

Според мен е от машината,няма начин да изтискаш много от нея!Можеш да си сложиш 2.6.X ядро по-бързо е и може да ти се вдигне малко трафика ама не очаквай много!А и още нещто този хард може да изкара много повече от това:

Цитат

hdparm -tT /dev/hde /dev/hde:  Timing buffer-cache reads:   128 MB in  3.56 seconds = 35.96 MB/sec  Timing buffered disk reads:  64 MB in  5.25 seconds = 12.19 MB/sec

Включи си DMA-то!
Разгледай тази статия:
http://www.linux-bg.org/cgi-bin....2767262

[Филип Бонев]

Здравей

Найстина машинката ти е слаба за файлов сървър или поне така мисля аз, но пробвай да сложиш нещо такова в самбата в global секцията:

Примерен код

TCP_NODELAY IPTOS_LOWDELAY SO_SNDBUF = 8192 SO_RCVBUF = 8192

При мене поне се изпълва макс на мрежата с тея настройки.

Успех.

[R4]

Привет,
наистина компютрите с Win2k са по-добри. Споменах това, главно за да покажа, че самата мрежичка може да поеме по-голямо натоварване, а и за да покажа към какво се стремя.

Статията за hdparm съм я чел, макар и не много старателно. Резултатът от hdparm -tT /dev/hde, който съм показал по-горе е при следните настройки:

Цитат

hdparm /dev/hde /dev/hde:  multcount    = 16 (on)  IO_support   =  3 (32-bit w/sync)  unmaskirq    =  1 (on)  using_dma    =  1 (on)  keepsettings =  0 (off)  readonly     =  0 (off)  readahead    =  8 (on)  geometry     = 9729/255/63, sectors = 156301488, start = 0

Ето и Global секцията на smb.conf. Пробвах тези параметри на   philip_bonev и сега съм с тях. Не мога да видя дали има разлика. Настройвам Самбата през Swat, но преди се мъчех на ръка.

Примерен код

# Global parameters [global]         workgroup = WORKGROUP         server string =         interfaces = eth0         bind interfaces only = Yes         socket options = TCP_NODELAY IPTOS_LOWDELAY SO_SNDBUF = 8192 SO_RCVBUF = 8192         wins support = Yes         ldap ssl = no

[ohubohu]

Да пусна и аз едно предложение:

Примерен код

elvtune /dev/hdX -b 4096

Имах подобен проблем/дразнител преди време и програмката ми ускори дисковия трансфер значително!
Обаче:
1. Не пипай другите настройки! Рисковано е!
2. Не работи под кернел 2.6...!

Късмет '>

[Филип Бонев]

Значи давам ти за сравнение мойта конфигурация на рутера в къщи. Pentium 200MHz, 64RAM, с вграден контролер Intel  с 2GB(QUANTUM FIREBALL SE2.1A) подържа само DMA и изкарава разни такива след hdparm -tT /dev/hda:

Цитат

/dev/hda:  Timing buffer-cache reads:    92 MB in  2.02 seconds =  45.46 MB/sec  Timing buffered disk reads:   26 MB in  3.39 seconds =   7.66 MB/sec

При тебе нещо май не е конфигурирано както трябва. Виж bios-а на райда, да ли има да пипнеш. Според мойте и твойте неща като гледам разликата трябва да e доста по гoляма.

[vladou]

Цитат

SO_SNDBUF = 8192 SO_RCVBUF = 8192

napravi tezi stojnostti na 65536.
Izpolzvai modula e100, kato si go izteglish ot support.intel.com poslednata versia. Tam ima edna opcia InterruptThrottlingRate. Ideyata e che mojesh da nakarash mrejovata ti karta da pravi po-malko prekusvania kum procesora i saotvetno da gulta po-malko CPU. V tozi moment experimentirai i sus TCP_NODELAY.

[stockton]

Само да добавя нещичко към препоръките на Владо - модула е100 има възможност да ползва един по-нов интерфейс към мрежовия стек,т.нар. NAPI. Идеята е,че при по-сериозни натоварвания кернела може да реши да игнорира прекъсванията от мрежовия хардуер и да "поеме нещата". В крайна сметка се постига по-ниско натоварване на процесора при сериозен packet rate. В интерес на истината,тази благинка ще е по-полезна за рутери,но не ти пречи да тестваш и за файлов сървър. Освен има какво да се оптимизира и в кернела по TCP часта,като даже не ти трябва да прекомпилираш - виж тук например: http://www.psc.edu/networking/perf_tune.html#Linux
А и Самбата подлежи на още малко тунинг от описания дотук:
http://k12linux.mesd.k12.or.us/using_samba/appb_02.html
Та в крайна сметка,нещата са комплексни - кернел,хардуер,файлова система,сървър приложението... Интересна занимавка,нали? '>
Успех, и сподели докъде си докарал тестовете!

[R4]

Здравейте  пак,
темичката е малко стара, но явлението, за което говоря си стои.

Преди да започна само искам да кажа, че едва днес видях поста на stockton.

Та днес си ровех из документацията на thttpd и вижте какво намерих тук:

Цитат

On the listen queue length: Many web admins think there are two main types of performance bottlenecks for a web server, the raw data rate of the network connection, and the CPU usage on the server machine. In fact there is a third common bottleneck that's still fairly obscure. If you run into this limit you may find that your web server isn't using much CPU, your network link isn't particularly full, and yet there are consistent complaints of timeouts and "connection refused" errors. It can be a very frustrating situation. Here's the deal: most versions of Unix have very short pending-connection queues. This queue is for connections waiting to be accept()ed, and typically it's of length 5. This puts a severe limit on how many connections/second the server can handle - if one comes in while the queue is full, it gets dropped on the floor and the client gets "connection refused". With only 5 slots in the queue, you'll start to see this behavior at around 3 connections/second. thttpd tries to minimize the effect of this limit by accepting new connections as fast as possible, and saving them in its own internal higher-capacity queue for later processing. Even so, for best performance you really want to make the system's queue longer, more like 32, which will handle maybe 10 to 20 connections/second. On Solaris systems you can increase the queue length with this command: /usr/sbin/ndd -set /dev/tcp tcp_conn_req_max 32 You have to run this as root, of course. This should go in the system startup script "/etc/rc2.d/S69inet". You can raise it higher than 32 if you like - if you're running Solaris 2.5 you can increase it to 1024, otherwise the limit is 512. On BSD/OS you use: /usr/bin/bpatch -l -r somaxconn 32 Not sure what the maximum is here. HP-UX 10.0 sets the default limit to 20, which is not too bad. Many other systems also have tiny queue limits - if I find out specifics on how to raise those limits, I'll put the info here.

Ясно е, че thttpd не е Самба, и обратно. Тук за мен е важно очевидното - има и други места, които спъват производителността. Както казах и преди натоварването на процесора ми при теглене през Самба никога не достига до 100%. Варира около 60-70%. Така че скоро ще видя написаното от stockton (очаквам да ми помогне) и отново ще пробвам написаното от philip_bonev, vladou и ohubohu.

[n_antonov]

Цитат (R4 @ Юли 06 2004,01:09)

Ето още нещо, което се сетих: hdparm -tT /dev/hde /dev/hde:  Timing buffer-cache reads:   128 MB in  3.56 seconds = 35.96 MB/sec  Timing buffered disk reads:  64 MB in  5.25 seconds = 12.19 MB/sec

Ами с толкова бавен диск къде си тръгнал'> Samba не може да прави чудеса. Иначе с малко фина настройка бие по скорст всякакъв Windows (при еднакъв хардуер) и се равнява на всяка TCP базирана файлова услуга, аналогична на FTP.

Включи в глобалната секция още две неща:

read raw = yes
write raw = yes

Но с този бавен диск си заникъде.

Ето това е софтуерен IDE RAID 1.

hdparm -tT /dev/md5

/dev/md5:
 Timing buffer-cache reads:   128 MB in  0.24 seconds =522.53 MB/sec
 Timing buffered disk reads:  64 MB in  1.39 seconds = 46.12 MB/sec

От този дял всякакви Winwows клиенти (основно XP, 98) теглят с повече от 30 мегабайта в секунда при 100 мегабитова мрежа. Което смятам за прилично.