[gentoo-user-ru] Насущный вопрос о тормозах при интенсивном I/O

[gentoo-user-ru] Насущный вопрос о тормозах при интенсивном I/O

[Охрименко Александр]

[-- Attachment #1: Type: text/plain, Size: 1048 bytes --]

Подскажите пожалуйста коллеги, кто нибудь использует Gentoo в
производственных целях? Я имею ввиду что делать с тормозами при i/o?
Т.е. в моем понимании Linux (Gentoo) должна позволять использовать
возможности железа на 100%, а я получаю дико тормозную систему,
вместо которой винда быстрее бы работала :( Кто как борется с этой проблемой
(кроме покупки новых HDD, SCSI и т.д.) ? Разработчики ядра
что нибудь чешут себе в поисках где они допустили ошибку, неужели никто не
может отЛАЖИвать этот процесс? Это проблема всех последних ядер
всех линуксов или только Gentoo?

наболело....

-- 
Охрименко А.А.

[-- Attachment #2: Type: text/html, Size: 1095 bytes --]

[gentoo-user-ru] Re: [gentoo-user-ru] Насущный вопрос о тормозах при интенсивном I/O

[Sergey Kobzar]

Monday, March 1, 2010, 6:00:06 PM, Охрименко wrote:

> Подскажите пожалуйста коллеги, кто нибудь использует Gentoo в
> производственных целях? Я имею ввиду что делать с тормозами при i/o? 
> Т.е. в моем понимании Linux (Gentoo) должна позволять использовать
> возможности железа на 100%, а я получаю дико тормозную систему,
> вместо которой винда быстрее бы работала   Кто как борется с этой
> проблемой (кроме покупки новых HDD, SCSI и т.д.) ? Разработчики ядра 
> что нибудь чешут себе в поисках где они допустили ошибку, неужели
> никто не может отЛАЖИвать этот процесс? Это проблема всех последних ядер
> всех линуксов или только Gentoo?

> наболело....

Это проблема (баг) ядра. Точнее целая связка.

У меня она появилась где-то в районе 2.6.22. На 2.6.3х немного легче,
но не так как на 2.6.19. Что-то пытаются сделать, но я бы не сказал
что с большим успехом. Не зря наверно RH + CentOS своих пользователей
еще на 2.6.18 держат ;)

Я вот подумываю о частичном переходе на FreeBSD.

Вопрос поднимался уже много раз.



-- 
Sergey

Re: [gentoo-user-ru] Re: [gentoo-user-ru] Насущный вопрос о тормозах при интенсивном I/O

[Kostya Sha]

А не со времён ли появления фичи CPU Group в ядре? И включена ли она у вас?

[gentoo-user-ru] Re[2]: [gentoo-user-ru] Re: [gentoo-user-ru] Насущный вопрос о тормозах при интенсивном I/O

[Sergey Kobzar]

Tuesday, March 9, 2010, 2:10:59 PM, Kostya wrote:

> А не со времён ли появления фичи CPU Group в ядре?

Точно не скажу.

> И включена ли она у вас?

Выключена.

-- 
Sergey

Re: [gentoo-user-ru] Re[2]: [gentoo-user-ru] Re: [gentoo-user-ru] Насущный вопрос о тормозах при интенсивном I/O

[KostyaSha]

Может попробовать включить и дать приоритет юзеру ?

Re: [gentoo-user-ru] Насущный вопрос о тормозах при интенсивном I/O

[Богун Дмитрий]

[-- Attachment #1: Type: text/plain, Size: 2734 bytes --]

В Пнд, 01/03/2010 в 18:00 +0200, Охрименко Александр пишет:
> Подскажите пожалуйста коллеги, кто нибудь использует Gentoo в
> производственных целях? Я имею ввиду что делать с тормозами при i/o? 
> Т.е. в моем понимании Linux (Gentoo) должна позволять использовать
> возможности железа на 100%, а я получаю дико тормозную систему,
> вместо которой винда быстрее бы работала :( Кто как борется с этой
> проблемой (кроме покупки новых HDD, SCSI и т.д.) ? Разработчики ядра 
> что нибудь чешут себе в поисках где они допустили ошибку, неужели
> никто не может отЛАЖИвать этот процесс? Это проблема всех последних
> ядер
> всех линуксов или только Gentoo?
> 
> наболело....
Вы бы хоть конфигурацию железа написали и ядро.

Раньше я никогда не сталкивался с особыми проблемами загрузки от io(в
линах с 2001-го), но недавно досталась мне машинка, которая ощутимо
тупит при нагрузке на диски.

Я связываю это с AMD'шной архитектурой(до того всегда пользовался
системами на базе интеловских процов). Ну вернее не столько с самим
процом, сколько с матерью под него. Возможно это и не так, но
полноценный тест провести сейчас не могу, нет "лишнего" железа.

По опросу народа, подтвердились проблемы с IO подсистемой на матерях c
nvidia чипом, но опять же это лишь гипотеза.

И на более свежее ядро перепозти сейчас не получится потому как дежат
vmware-modules

Инфа по системе в аттаче.

ЗЫ На боевых системах гента пректасно трудится, но там извините другое
железо и как правило железные raid'ы.
ЗЫЫ Я не сторонних святых войн, говорю лишь то что знаю из своего опыта.

[-- Attachment #2: info --]
[-- Type: text/plain, Size: 3731 bytes --]

Portage 2.1.7.16 (default/linux/x86/10.0/desktop, gcc-4.3.4, glibc-2.10.1-r1, 2.6.29.6 i686)
=================================================================
System uname: Linux-2.6.29.6-i686-AMD_Phenom-tm-_9650_Quad-Core_Processor-with-gentoo-1.12.13
Timestamp of tree: Sat, 27 Feb 2010 01:00:01 +0000
app-shells/bash:     4.0_p35
dev-java/java-config: 2.1.10
dev-lang/python:     2.6.4
dev-util/cmake:      2.6.4-r3
sys-apps/baselayout: 1.12.13
sys-apps/sandbox:    1.6-r2
sys-devel/autoconf:  2.13, 2.63-r1
sys-devel/automake:  1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r3, 1.10.3, 1.11.1
sys-devel/binutils:  2.18-r3
sys-devel/gcc:       4.3.4
sys-devel/gcc-config: 1.4.1
sys-devel/libtool:   2.2.6b
virtual/os-headers:  2.6.30-r1
ACCEPT_KEYWORDS="x86"
ACCEPT_LICENSE="* -@EULA skype-eula dlj-1.1 Q3AEULA"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-march=k8 -O2 -pipe"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/X11/xkb /usr/share/config"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/eselect/postgresql /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/udev/rules.d"
CXXFLAGS="-march=k8 -O2 -pipe"
DISTDIR="/usr/share/portdir/distfiles"
FEATURES="assume-digests distlocks fixpackages news parallel-fetch protect-owned sandbox sfperms strict unmerge-logs unmerge-orphans userfetch"
GENTOO_MIRRORS="http://adm.vugluskr.org.ua/gentoo-portage/ http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo"
LANG="ru_RU.UTF-8"
LDFLAGS="-Wl,-O1"
LINGUAS="en ru"
MAKEOPTS="-j4"
PKGDIR="/usr/share/portdir/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/share/portdir"
PORTDIR_OVERLAY="/usr/share/portdir/local/layman/vugluskr"
SYNC="rsync://portage.home.lan/gentoo-portage"
USE="3dnow 3dnowext X a52 aac acl acpi alsa berkdb bluetooth branding bzip2 cairo cdr cli consolekit cracklib crypt cxx dbus dri dts dvd dvdr eds emboss encode evo exif fam firefox flac fontconfig fortran gdbm gif gpm gstreamer gtk gzip hal iconv ipv6 jpeg kde ldap libnotify logrotate mad mikmod mmx mmxext mng modules mp3 mp4 mpeg mudflap ncurses nls nptl nptlonly ogg opengl openmp pam pcre pdf perl png ppds pppd python qt3support qt4 quicktime readline reflection sdl session snmp spell spl sse sse2 ssl startup-notification svg sysfs syslog thunar tiff truetype unicode usb vim-syntax vorbis win32codecs x264 x86 xattr xinetd xml xorg xulrunner xv xvid zlib" ALSA_CARDS="hda-intel serial-u16550" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias autoindex dav dav_fs dav_lock expires rewrite     auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm      authz_default authz_groupfile authz_host authz_owner authz_user      cache file_cache dir disk_cache env ext_filter filter headers     include info log_config logio mem_cache mime mime_magic negotiation     status unique_id userdir usertrack vhost_alias" APACHE2_MPMS="prefork" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en ru" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="nvidia nv vga" 
Unset:  CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS


[-- Attachment #3: lshw --]
[-- Type: text/plain, Size: 29034 bytes --]

shana
    description: Desktop Computer
    product: System Product Name
    vendor: System manufacturer
    version: System Version
    serial: System Serial Number
    width: 32 bits
    capabilities: smp-1.4 smp
    configuration: boot=normal chassis=desktop cpus=4 uuid=6026001E-8C00-01C6-D025-00248C3F918E
  *-core
       description: Motherboard
       product: M3N78 PRO
       vendor: ASUSTeK Computer INC.
       physical id: 0
       version: 1.XX
       serial: MS1C92B33D00900
     *-firmware
          description: BIOS
          vendor: Phoenix Technologies, LTD
          physical id: 0
          version: ASUS M3N78 PRO ACPI BIOS Revision 0701 (01/06/2009)
          size: 128KiB
          capacity: 960KiB
          capabilities: pci pnp apm upgrade shadowing cdboot bootselect socketedrom edd int13floppy360 int13floppy1200 int13floppy720 int13floppy2880 int5printscreen int9keyboard int14serial int17printer int10video acpi usb ls120boot zipboot biosbootspecification
     *-cpu:0
          description: CPU
          product: AMD Phenom(tm) 9650 Quad-Core Processor
          vendor: Advanced Micro Devices [AMD]
          physical id: 3
          bus info: cpu@0
          version: 15.2.3
          slot: Socket AM2
          size: 2300MHz
          capacity: 3700MHz
          width: 64 bits
          clock: 200MHz
          capabilities: boot fpu fpu_exception wp vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp x86-64 3dnowext 3dnow constant_tsc nonstop_tsc pni monitor cx16 lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs
        *-cache:0
             description: L1 cache
             physical id: 5
             slot: L1 Cache
             size: 256KiB
             capacity: 256KiB
             capabilities: synchronous internal write-back data
        *-cache:1
             description: L2 cache
             physical id: 6
             slot: L2 Cache
             size: 1MiB
             capacity: 1MiB
             capabilities: synchronous internal write-back unified
     *-memory:0
          description: System Memory
          physical id: 28
          slot: System board or motherboard
          size: 4GiB
        *-bank:0
             description: DIMM DDR2 800 MHz (1.2 ns)
             product: None
             vendor: None
             physical id: 0
             serial: None
             slot: DIMM_A1
             size: 2GiB
             width: 64 bits
             clock: 800MHz (1.2ns)
        *-bank:1
             description: DIMM DDR2 800 MHz (1.2 ns)
             product: None
             vendor: None
             physical id: 1
             serial: None
             slot: DIMM_B1
             size: 2GiB
             width: 64 bits
             clock: 800MHz (1.2ns)
        *-bank:2
             description: DIMM [empty]
             product: None
             vendor: None
             physical id: 2
             serial: None
             slot: DIMM_A2
             width: 64 bits
        *-bank:3
             description: DIMM [empty]
             product: None
             vendor: None
             physical id: 3
             serial: None
             slot: DIMM_B2
             width: 64 bits
     *-cpu:1
          physical id: 4
          bus info: cpu@1
          version: 15.2.3
          size: 2300MHz
     *-cpu:2
          physical id: 5
          bus info: cpu@2
          version: 15.2.3
          size: 2300MHz
     *-cpu:3
          physical id: c
          bus info: cpu@3
          version: 15.2.3
          size: 2300MHz
     *-memory:1 UNCLAIMED
          description: RAM memory
          product: MCP78S [GeForce 8200] Memory Controller
          vendor: nVidia Corporation
          physical id: d
          bus info: pci@0000:00:00.0
          version: a2
          width: 32 bits
          clock: 66MHz (15.2ns)
          capabilities: ht bus_master cap_list
          configuration: latency=0
     *-isa
          description: ISA bridge
          product: MCP78S [GeForce 8200] LPC Bridge
          vendor: nVidia Corporation
          physical id: 1
          bus info: pci@0000:00:01.0
          version: a2
          width: 32 bits
          clock: 66MHz
          capabilities: isa bus_master
          configuration: latency=0
     *-serial UNCLAIMED
          description: SMBus
          product: MCP78S [GeForce 8200] SMBus
          vendor: nVidia Corporation
          physical id: 1.1
          bus info: pci@0000:00:01.1
          version: a1
          width: 32 bits
          clock: 66MHz
          capabilities: pm cap_list
          configuration: latency=0
          resources: ioport:ff00(size=64) ioport:1c00(size=64) ioport:1c40(size=64)
     *-memory:2 UNCLAIMED
          description: RAM memory
          product: MCP78S [GeForce 8200] Memory Controller
          vendor: nVidia Corporation
          physical id: 1.2
          bus info: pci@0000:00:01.2
          version: a1
          width: 32 bits
          clock: 66MHz (15.2ns)
          configuration: latency=0
     *-processor UNCLAIMED
          description: Co-processor
          product: MCP78S [GeForce 8200] Co-Processor
          vendor: nVidia Corporation
          physical id: 1.3
          bus info: pci@0000:00:01.3
          version: a2
          width: 32 bits
          clock: 66MHz
          capabilities: bus_master
          configuration: latency=0 maxlatency=1 mingnt=3
          resources: memory:fdf80000-fdffffff
     *-memory:3 UNCLAIMED
          description: RAM memory
          product: MCP78S [GeForce 8200] Memory Controller
          vendor: nVidia Corporation
          physical id: 1.4
          bus info: pci@0000:00:01.4
          version: a1
          width: 32 bits
          clock: 66MHz (15.2ns)
          configuration: latency=0
     *-usb:0
          description: USB Controller
          product: MCP78S [GeForce 8200] OHCI USB 1.1 Controller
          vendor: nVidia Corporation
          physical id: 2
          bus info: pci@0000:00:02.0
          version: a1
          width: 32 bits
          clock: 66MHz
          capabilities: pm ohci bus_master cap_list
          configuration: driver=ohci_hcd latency=0 maxlatency=1 mingnt=3
          resources: irq:20 memory:fe02f000-fe02ffff
        *-usbhost
             product: OHCI Host Controller
             vendor: Linux 2.6.29.6 ohci_hcd
             physical id: 1
             bus info: usb@3
             logical name: usb3
             version: 2.06
             capabilities: usb-1.10
             configuration: driver=hub slots=6 speed=12.0MB/s
     *-usb:1
          description: USB Controller
          product: MCP78S [GeForce 8200] EHCI USB 2.0 Controller
          vendor: nVidia Corporation
          physical id: 2.1
          bus info: pci@0000:00:02.1
          version: a1
          width: 32 bits
          clock: 66MHz
          capabilities: debug pm ehci bus_master cap_list
          configuration: driver=ehci_hcd latency=0 maxlatency=1 mingnt=3
          resources: irq:22 memory:fe02e000-fe02e0ff
        *-usbhost
             product: EHCI Host Controller
             vendor: Linux 2.6.29.6 ehci_hcd
             physical id: 1
             bus info: usb@1
             logical name: usb1
             version: 2.06
             capabilities: usb-2.00
             configuration: driver=hub slots=6 speed=480.0MB/s
           *-usb
                description: Mass storage device
                product: My Book
                vendor: Western Digital
                physical id: 1
                bus info: usb@1:1
                logical name: scsi8
                version: 10.28
                serial: 57442D574341553441353834383532
                capabilities: usb-2.00 scsi emulated scsi-host
                configuration: driver=usb-storage speed=480.0MB/s
              *-disk
                   description: SCSI Disk
                   product: My Book
                   vendor: WD
                   physical id: 0.0.0
                   bus info: scsi@8:0.0.0
                   logical name: /dev/sde
                   version: 1028
                   size: 931GiB (1TB)
                   capabilities: partitioned partitioned:dos
                   configuration: ansiversion=4 signature=acdd9b22
                 *-volume:0
                      description: EXT3 volume
                      vendor: Linux
                      physical id: 1
                      bus info: scsi@8:0.0.0,1
                      logical name: /dev/sde1
                      version: 1.0
                      serial: 3b084e12-5f92-4610-a055-77af8e6599b1
                      size: 6142MiB
                      capacity: 6142MiB
                      capabilities: primary bootable journaled extended_attributes large_files ext3 ext2 initialized
                      configuration: created=2009-10-16 21:14:57 filesystem=ext3 label=kuroi-neko-/ modified=2009-11-04 12:50:31 mounted=2009-11-04 12:26:50 state=clean
                 *-volume:1
                      description: EXT3 volume
                      vendor: Linux
                      physical id: 2
                      bus info: scsi@8:0.0.0,2
                      logical name: /dev/sde2
                      version: 1.0
                      serial: 1bfa7696-da24-4860-84c9-88616ceebd00
                      size: 20GiB
                      capacity: 20GiB
                      capabilities: primary journaled extended_attributes large_files ext3 ext2 initialized
                      configuration: created=2009-09-16 00:14:36 filesystem=ext3 label=book-000 modified=2010-02-12 15:28:51 mounted=2010-02-12 15:28:37 state=clean
                 *-volume:2
                      description: EXT3 volume
                      vendor: Linux
                      physical id: 3
                      bus info: scsi@8:0.0.0,3
                      logical name: /dev/sde3
                      logical name: /media/disk
                      version: 1.0
                      serial: 0d8abd3b-49e0-4a39-99ae-fbd2b25acef7
                      size: 905GiB
                      capacity: 905GiB
                      capabilities: primary journaled extended_attributes large_files recover ext3 ext2 initialized
                      configuration: created=2009-10-16 21:15:11 filesystem=ext3 modified=2010-02-21 00:37:19 mount.fstype=ext3 mount.options=rw,nosuid,nodev,errors=continue,data=ordered mounted=2010-02-21 00:37:19 state=mounted
     *-usb:2
          description: USB Controller
          product: MCP78S [GeForce 8200] OHCI USB 1.1 Controller
          vendor: nVidia Corporation
          physical id: e
          bus info: pci@0000:00:04.0
          version: a1
          width: 32 bits
          clock: 66MHz
          capabilities: pm ohci bus_master cap_list
          configuration: driver=ohci_hcd latency=0 maxlatency=1 mingnt=3
          resources: irq:23 memory:fe02d000-fe02dfff
        *-usbhost
             product: OHCI Host Controller
             vendor: Linux 2.6.29.6 ohci_hcd
             physical id: 1
             bus info: usb@4
             logical name: usb4
             version: 2.06
             capabilities: usb-1.10
             configuration: driver=hub slots=6 speed=12.0MB/s
           *-usb
                description: Mouse
                product: Optical Mouse
                vendor: Genius
                physical id: 1
                bus info: usb@4:1
                version: 1.00
                capabilities: usb-1.10
                configuration: driver=usbhid maxpower=100mA speed=1.5MB/s
     *-usb:3
          description: USB Controller
          product: MCP78S [GeForce 8200] EHCI USB 2.0 Controller
          vendor: nVidia Corporation
          physical id: 4.1
          bus info: pci@0000:00:04.1
          version: a1
          width: 32 bits
          clock: 66MHz
          capabilities: debug pm ehci bus_master cap_list
          configuration: driver=ehci_hcd latency=0 maxlatency=1 mingnt=3
          resources: irq:21 memory:fe02c000-fe02c0ff
        *-usbhost
             product: EHCI Host Controller
             vendor: Linux 2.6.29.6 ehci_hcd
             physical id: 1
             bus info: usb@2
             logical name: usb2
             version: 2.06
             capabilities: usb-2.00
             configuration: driver=hub slots=6 speed=480.0MB/s
     *-ide
          description: IDE interface
          product: MCP78S [GeForce 8200] IDE
          vendor: nVidia Corporation
          physical id: 6
          bus info: pci@0000:00:06.0
          version: a1
          width: 32 bits
          clock: 66MHz
          capabilities: ide pm bus_master cap_list
          configuration: driver=pata_amd latency=0 maxlatency=1 mingnt=3
          resources: irq:0 ioport:1f0(size=8) ioport:3f6 ioport:170(size=8) ioport:376 ioport:fc00(size=16)
     *-multimedia
          description: Audio device
          product: MCP72XE/MCP72P/MCP78U/MCP78S High Definition Audio
          vendor: nVidia Corporation
          physical id: 7
          bus info: pci@0000:00:07.0
          version: a1
          width: 32 bits
          clock: 66MHz
          capabilities: pm msi ht bus_master cap_list
          configuration: driver=HDA Intel latency=0 maxlatency=5 mingnt=2
          resources: irq:21 memory:fe020000-fe023fff
     *-pci:0
          description: PCI bridge
          product: MCP78S [GeForce 8200] PCI Bridge
          vendor: nVidia Corporation
          physical id: 8
          bus info: pci@0000:00:08.0
          version: a1
          width: 32 bits
          clock: 66MHz
          capabilities: pci ht subtractive_decode bus_master cap_list
          resources: ioport:e000(size=4096) memory:fde00000-fdefffff memory:fdd00000-fddfffff(prefetchable)
        *-network DISABLED
             description: Ethernet interface
             product: RTL8139D [Realtek] PCI 10/100BaseTX ethernet adaptor
             vendor: Hangzhou Silan Microelectronics Co., Ltd.
             physical id: 9
             bus info: pci@0000:01:09.0
             logical name: eth1
             version: 01
             serial: 00:e0:20:00:7b:e5
             size: 10MB/s
             capacity: 100MB/s
             width: 32 bits
             clock: 33MHz
             capabilities: pm vpd bus_master cap_list rom ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd autonegotiation
             configuration: autonegotiation=on broadcast=yes driver=sc92031 driverversion=2.0c duplex=half latency=32 link=yes maxlatency=40 mingnt=20 multicast=yes port=MII speed=10MB/s
             resources: irq:17 memory:fdeff000-fdeff0ff ioport:ec00(size=256) memory:fdd00000-fdd1ffff(prefetchable)
        *-firewire
             description: FireWire (IEEE 1394)
             product: FW322/323
             vendor: Agere Systems
             physical id: a
             bus info: pci@0000:01:0a.0
             version: 70
             width: 32 bits
             clock: 33MHz
             capabilities: pm ohci bus_master cap_list
             configuration: driver=ohci1394 latency=32 maxlatency=24 mingnt=12
             resources: irq:19 memory:fdefe000-fdefefff
     *-storage
          description: SATA controller
          product: MCP78S [GeForce 8200] AHCI Controller
          vendor: nVidia Corporation
          physical id: 9
          bus info: pci@0000:00:09.0
          logical name: scsi0
          logical name: scsi1
          logical name: scsi2
          logical name: scsi3
          version: a2
          width: 32 bits
          clock: 66MHz
          capabilities: storage pm msi ht ahci_1.0 bus_master cap_list emulated
          configuration: driver=ahci latency=0 maxlatency=1 mingnt=3
          resources: irq:28 ioport:9f0(size=8) ioport:bf0(size=4) ioport:970(size=8) ioport:b70(size=4) ioport:f700(size=16) memory:fe026000-fe027fff
        *-disk:0
             description: ATA Disk
             product: WDC WD5001AALS-0
             vendor: Western Digital
             physical id: 0
             bus info: scsi@0:0.0.0
             logical name: /dev/sda
             version: 01.0
             serial: WD-WCASZ0272460
             size: 465GiB (500GB)
             capabilities: partitioned partitioned:dos
             configuration: ansiversion=5 signature=2b5e0c85
           *-volume:0
                description: Linux raid autodetect partition
                vendor: Linux
                physical id: 1
                bus info: scsi@0:0.0.0,1
                logical name: /dev/sda1
                version: 1.0
                serial: c3403f6d-bd11-448f-bf31-25326ded8bff
                size: 39MiB
                capacity: 39MiB
                capabilities: primary bootable multi extended_attributes ext2 initialized
                configuration: filesystem=ext2 label=kagami-/boot modified=2010-02-16 02:13:21 mounted=2010-02-16 02:13:21 state=clean
           *-volume:1
                description: Extended partition
                physical id: 2
                bus info: scsi@0:0.0.0,2
                logical name: /dev/sda2
                size: 465GiB
                capacity: 465GiB
                capabilities: primary extended partitioned partitioned:extended
              *-logicalvolume
                   description: Linux raid autodetect partition
                   physical id: 5
                   logical name: /dev/sda5
                   capacity: 465GiB
                   capabilities: multi
        *-disk:1
             description: ATA Disk
             product: ST3320620AS
             vendor: Seagate
             physical id: 1
             bus info: scsi@1:0.0.0
             logical name: /dev/sdb
             version: 3.AA
             serial: 6QF1G75B
             size: 298GiB (320GB)
             capabilities: partitioned partitioned:dos
             configuration: ansiversion=5
           *-volume:0
                description: Linux filesystem partition
                vendor: Linux
                physical id: 1
                bus info: scsi@1:0.0.0,1
                logical name: /dev/sdb1
                logical name: /boot
                version: 1.0
                serial: ee780660-c8ee-4a09-af60-c78c53fbe8a9
                size: 31MiB
                capacity: 31MiB
                capabilities: primary bootable ext2 initialized
                configuration: filesystem=ext2 label=shana-/boot modified=2010-02-15 21:26:25 mount.fstype=ext2 mount.options=ro,noatime,errors=continue mounted=2010-02-15 21:26:25 state=mounted
           *-volume:1
                description: Linux raid autodetect partition
                physical id: 2
                bus info: scsi@1:0.0.0,2
                logical name: /dev/sdb2
                capacity: 17GiB
                capabilities: primary multi
           *-volume:2
                description: Extended partition
                physical id: 3
                bus info: scsi@1:0.0.0,3
                logical name: /dev/sdb3
                size: 280GiB
                capacity: 280GiB
                capabilities: primary extended partitioned partitioned:extended
              *-logicalvolume:0
                   description: Linux swap / Solaris partition
                   physical id: 5
                   logical name: /dev/sdb5
                   capacity: 972MiB
                   capabilities: nofs
              *-logicalvolume:1
                   description: Linux LVM Physical Volume partition
                   physical id: 6
                   logical name: /dev/sdb6
                   serial: 6nwHoX-bde2-KdVA-QXLV-E1Ra-bsE0-SpAx1L
                   size: 279GiB
                   capacity: 279GiB
                   capabilities: multi lvm2
        *-disk:2
             description: ATA Disk
             product: WDC WD5001AALS-0
             vendor: Western Digital
             physical id: 2
             bus info: scsi@2:0.0.0
             logical name: /dev/sdc
             version: 01.0
             serial: WD-WCASZ0263068
             size: 465GiB (500GB)
             capabilities: partitioned partitioned:dos
             configuration: ansiversion=5
           *-volume:0
                description: Linux raid autodetect partition
                vendor: Linux
                physical id: 1
                bus info: scsi@2:0.0.0,1
                logical name: /dev/sdc1
                version: 1.0
                serial: c3403f6d-bd11-448f-bf31-25326ded8bff
                size: 39MiB
                capacity: 39MiB
                capabilities: primary bootable multi extended_attributes ext2 initialized
                configuration: filesystem=ext2 label=kagami-/boot modified=2010-02-16 02:13:21 mounted=2010-02-16 02:13:21 state=clean
           *-volume:1
                description: Extended partition
                physical id: 2
                bus info: scsi@2:0.0.0,2
                logical name: /dev/sdc2
                size: 465GiB
                capacity: 465GiB
                capabilities: primary extended partitioned partitioned:extended
              *-logicalvolume
                   description: Linux raid autodetect partition
                   physical id: 5
                   logical name: /dev/sdc5
                   capacity: 465GiB
                   capabilities: multi
        *-disk:3
             description: ATA Disk
             product: ST3320620AS
             vendor: Seagate
             physical id: 3
             bus info: scsi@3:0.0.0
             logical name: /dev/sdd
             version: 3.AA
             serial: 6QF1G8PZ
             size: 298GiB (320GB)
             capabilities: partitioned partitioned:dos
             configuration: ansiversion=5
           *-volume:0
                description: Linux filesystem partition
                vendor: Linux
                physical id: 1
                bus info: scsi@3:0.0.0,1
                logical name: /dev/sdd1
                version: 1.0
                serial: a5e88bb9-0343-4475-94b3-d54c1a2b30e4
                size: 31MiB
                capacity: 31MiB
                capabilities: primary bootable ext2 initialized
                configuration: filesystem=ext2 label=shana-/boot.0 modified=2007-08-19 20:27:07 mounted=2007-08-19 20:25:30 state=clean
           *-volume:1
                description: Linux raid autodetect partition
                physical id: 2
                bus info: scsi@3:0.0.0,2
                logical name: /dev/sdd2
                capacity: 17GiB
                capabilities: primary multi
           *-volume:2
                description: Extended partition
                physical id: 3
                bus info: scsi@3:0.0.0,3
                logical name: /dev/sdd3
                size: 280GiB
                capacity: 280GiB
                capabilities: primary extended partitioned partitioned:extended
              *-logicalvolume:0
                   description: Linux swap / Solaris partition
                   physical id: 5
                   logical name: /dev/sdd5
                   capacity: 972MiB
                   capabilities: nofs
              *-logicalvolume:1
                   description: Linux LVM Physical Volume partition
                   physical id: 6
                   logical name: /dev/sdd6
                   serial: lXkJGN-O1DZ-2GL8-1bTR-xo0Q-PTw0-Pb6Uti
                   size: 279GiB
                   capacity: 279GiB
                   capabilities: multi lvm2
     *-network
          description: Ethernet interface
          product: MCP77 Ethernet
          vendor: nVidia Corporation
          physical id: a
          bus info: pci@0000:00:0a.0
          logical name: eth0
          version: a2
          serial: 00:24:8c:3f:91:8e
          size: 100MB/s
          capacity: 1GB/s
          width: 32 bits
          clock: 66MHz
          capabilities: pm msi ht bus_master cap_list ethernet physical mii 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
          configuration: autonegotiation=on broadcast=yes driver=forcedeth driverversion=0.62 duplex=full ip=192.168.214.2 latency=0 link=yes maxlatency=20 mingnt=1 multicast=yes port=MII speed=100MB/s
          resources: irq:29 memory:fe02b000-fe02bfff ioport:f600(size=8) memory:fe02a000-fe02a0ff memory:fe029000-fe02900f
     *-pci:1
          description: PCI bridge
          product: MCP78S [GeForce 8200] PCI Express Bridge
          vendor: nVidia Corporation
          physical id: b
          bus info: pci@0000:00:0b.0
          version: a1
          width: 32 bits
          clock: 33MHz
          capabilities: pci pm ht normal_decode bus_master cap_list
          resources: ioport:d000(size=4096) memory:fb000000-fcffffff ioport:d8000000(size=268435456)
        *-display
             description: VGA compatible controller
             product: C77 [GeForce 8300]
             vendor: nVidia Corporation
             physical id: 0
             bus info: pci@0000:02:00.0
             version: a2
             width: 64 bits
             clock: 33MHz
             capabilities: pm msi vga_controller bus_master cap_list rom
             configuration: driver=nvidia latency=0
             resources: irq:20 memory:fb000000-fbffffff memory:d8000000-dfffffff(prefetchable) memory:e6000000-e7ffffff(prefetchable) ioport:dc00(size=128) memory:e0000000-e001ffff(prefetchable)
     *-pci:2
          description: PCI bridge
          product: MCP78S [GeForce 8200] PCI Express Bridge
          vendor: nVidia Corporation
          physical id: 10
          bus info: pci@0000:00:10.0
          version: a1
          width: 32 bits
          clock: 33MHz
          capabilities: pci pm msi ht pciexpress normal_decode bus_master cap_list
          configuration: driver=pcieport-driver
          resources: irq:24 ioport:c000(size=4096) memory:fdc00000-fdcfffff ioport:fdb00000(size=1048576)
     *-pci:3
          description: PCI bridge
          product: MCP78S [GeForce 8200] PCI Express Bridge
          vendor: nVidia Corporation
          physical id: 12
          bus info: pci@0000:00:12.0
          version: a1
          width: 32 bits
          clock: 33MHz
          capabilities: pci pm msi ht pciexpress normal_decode bus_master cap_list
          configuration: driver=pcieport-driver
          resources: irq:25 ioport:b000(size=4096) memory:fda00000-fdafffff ioport:fd900000(size=1048576)
     *-pci:4
          description: PCI bridge
          product: MCP78S [GeForce 8200] PCI Bridge
          vendor: nVidia Corporation
          physical id: 13
          bus info: pci@0000:00:13.0
          version: a1
          width: 32 bits
          clock: 33MHz
          capabilities: pci pm msi ht pciexpress normal_decode bus_master cap_list
          configuration: driver=pcieport-driver
          resources: irq:26 ioport:a000(size=4096) memory:fd800000-fd8fffff ioport:fd700000(size=1048576)
     *-pci:5
          description: PCI bridge
          product: MCP78S [GeForce 8200] PCI Bridge
          vendor: nVidia Corporation
          physical id: 14
          bus info: pci@0000:00:14.0
          version: a1
          width: 32 bits
          clock: 33MHz
          capabilities: pci pm msi ht pciexpress normal_decode bus_master cap_list
          configuration: driver=pcieport-driver
          resources: irq:27 ioport:9000(size=4096) memory:fd600000-fd6fffff ioport:fd500000(size=1048576)
     *-pci:6
          description: Host bridge
          product: K10 [Opteron, Athlon64, Sempron] HyperTransport Configuration
          vendor: Advanced Micro Devices [AMD]
          physical id: 100
          bus info: pci@0000:00:18.0
          version: 00
          width: 32 bits
          clock: 33MHz
     *-pci:7
          description: Host bridge
          product: K10 [Opteron, Athlon64, Sempron] Address Map
          vendor: Advanced Micro Devices [AMD]
          physical id: 101
          bus info: pci@0000:00:18.1
          version: 00
          width: 32 bits
          clock: 33MHz
     *-pci:8
          description: Host bridge
          product: K10 [Opteron, Athlon64, Sempron] DRAM Controller
          vendor: Advanced Micro Devices [AMD]
          physical id: 102
          bus info: pci@0000:00:18.2
          version: 00
          width: 32 bits
          clock: 33MHz
     *-pci:9
          description: Host bridge
          product: K10 [Opteron, Athlon64, Sempron] Miscellaneous Control
          vendor: Advanced Micro Devices [AMD]
          physical id: 103
          bus info: pci@0000:00:18.3
          version: 00
          width: 32 bits
          clock: 33MHz
     *-pci:10
          description: Host bridge
          product: K10 [Opteron, Athlon64, Sempron] Link Control
          vendor: Advanced Micro Devices [AMD]
          physical id: 104
          bus info: pci@0000:00:18.4
          version: 00
          width: 32 bits
          clock: 33MHz

[gentoo-user-ru] Re[2]: [gentoo-user-ru] Насущный вопрос о тормозах при интенсивном I/O

[Sergey Kobzar]

Monday, March 1, 2010, 6:34:41 PM, Богун wrote:

> Вы бы хоть конфигурацию железа написали и ядро.

> Раньше я никогда не сталкивался с особыми проблемами загрузки от io(в
> линах с 2001-го), но недавно досталась мне машинка, которая ощутимо
> тупит при нагрузке на диски.

> Я связываю это с AMD'шной архитектурой(до того всегда пользовался
> системами на базе интеловских процов). Ну вернее не столько с самим
> процом, сколько с матерью под него. Возможно это и не так, но
> полноценный тест провести сейчас не могу, нет "лишнего" железа.

> По опросу народа, подтвердились проблемы с IO подсистемой на матерях c
> nvidia чипом, но опять же это лишь гипотеза.

На Intel (Xeon) те же яйца.


> И на более свежее ядро перепозти сейчас не получится потому как дежат
> vmware-modules

VMware Server 2.х работает на > 2.6.27, но уродливое оно какое-то.


> Инфа по системе в аттаче.

> ЗЫ На боевых системах гента пректасно трудится, но там извините другое
> железо и как правило железные raid'ы.

На железных рэйдах дикие тормоза аналогично. LA при дисковой нагрузке
поднимается >6 на ядрах >2.6.19, в то время, как на 2.6.19 LA >2 не
наблюдается.

> ЗЫЫ Я не сторонних святых войн, говорю лишь то что знаю из своего опыта.

Аналогично

-- 
Sergey

[gentoo-user-ru] Re: [gentoo-user-ru] Re[2]: [gentoo-user-ru] Насущный вопрос о тормозах при интенсивном I/O

[Sergey Kobzar]

Monday, March 1, 2010, 7:04:52 PM, Sergey wrote:

> Monday, March 1, 2010, 6:34:41 PM, Богун wrote:

>> Вы бы хоть конфигурацию железа написали и ядро.

>> Раньше я никогда не сталкивался с особыми проблемами загрузки от io(в
>> линах с 2001-го), но недавно досталась мне машинка, которая ощутимо
>> тупит при нагрузке на диски.

>> Я связываю это с AMD'шной архитектурой(до того всегда пользовался
>> системами на базе интеловских процов). Ну вернее не столько с самим
>> процом, сколько с матерью под него. Возможно это и не так, но
>> полноценный тест провести сейчас не могу, нет "лишнего" железа.

>> По опросу народа, подтвердились проблемы с IO подсистемой на матерях c
>> nvidia чипом, но опять же это лишь гипотеза.

> На Intel (Xeon) те же яйца.


>> И на более свежее ядро перепозти сейчас не получится потому как дежат
>> vmware-modules

> VMware Server 2.х работает на > 2.6.27, но уродливое оно какое-то.


>> Инфа по системе в аттаче.

>> ЗЫ На боевых системах гента пректасно трудится, но там извините другое
>> железо и как правило железные raid'ы.

> На железных рэйдах дикие тормоза аналогично. LA при дисковой нагрузке
поднимается >>6 на ядрах >2.6.19, в то время, как на 2.6.19 LA >2 не
> наблюдается.

>> ЗЫЫ Я не сторонних святых войн, говорю лишь то что знаю из своего опыта.

> Аналогично

Да, Linux стает буквой Z если на диск пишет одновременно неск.
процессов. dd результата не даст. Запустите в VMware 3-4 виртуальных
машины и сразу поймете о чем я ;)


-- 
Sergey

[gentoo-user-ru] Re: [gentoo-user-ru] Re: [gentoo-user-ru] Re[2]: [gentoo-user-ru] Насущный вопрос о тормозах при интенсивном I/O

[Охрименко Александр]

[-- Attachment #1: Type: text/plain, Size: 2928 bytes --]

Главный вопрос: как бороться? Кому что помогло? В прошлой рассылке кто то
давал ссылку на англоязычные рекомендации, делал, не помогало ощутимо.

1 марта 2010 г. 19:09 пользователь Sergey Kobzar <sergey.kobzar@mail.ru>написал:

> Monday, March 1, 2010, 7:04:52 PM, Sergey wrote:
>
> > Monday, March 1, 2010, 6:34:41 PM, Богун wrote:
>
> >> Вы бы хоть конфигурацию железа написали и ядро.
>
> >> Раньше я никогда не сталкивался с особыми проблемами загрузки от io(в
> >> линах с 2001-го), но недавно досталась мне машинка, которая ощутимо
> >> тупит при нагрузке на диски.
>
> >> Я связываю это с AMD'шной архитектурой(до того всегда пользовался
> >> системами на базе интеловских процов). Ну вернее не столько с самим
> >> процом, сколько с матерью под него. Возможно это и не так, но
> >> полноценный тест провести сейчас не могу, нет "лишнего" железа.
>
> >> По опросу народа, подтвердились проблемы с IO подсистемой на матерях c
> >> nvidia чипом, но опять же это лишь гипотеза.
>
> > На Intel (Xeon) те же яйца.
>
>
> >> И на более свежее ядро перепозти сейчас не получится потому как дежат
> >> vmware-modules
>
> > VMware Server 2.х работает на > 2.6.27, но уродливое оно какое-то.
>
>
> >> Инфа по системе в аттаче.
>
> >> ЗЫ На боевых системах гента пректасно трудится, но там извините другое
> >> железо и как правило железные raid'ы.
>
> > На железных рэйдах дикие тормоза аналогично. LA при дисковой нагрузке
> поднимается >>6 на ядрах >2.6.19, в то время, как на 2.6.19 LA >2 не
> > наблюдается.
>
> >> ЗЫЫ Я не сторонних святых войн, говорю лишь то что знаю из своего опыта.
>
> > Аналогично
>
> Да, Linux стает буквой Z если на диск пишет одновременно неск.
> процессов. dd результата не даст. Запустите в VMware 3-4 виртуальных
> машины и сразу поймете о чем я ;)
>
>
> --
> Sergey
>
>
>


-- 
Охрименко А.А.

[-- Attachment #2: Type: text/html, Size: 3511 bytes --]

[gentoo-user-ru] Re: [gentoo-user-ru] Re: [gentoo-user-ru] Re: [gentoo-user-ru] Re[2]: [gentoo-user-ru] Насущный вопрос о тормозах при интенсивном I/O

[Sergey Kobzar]

Monday, March 1, 2010, 8:21:26 PM, Охрименко wrote:

> Главный вопрос: как бороться? Кому что помогло? В прошлой рассылке
> кто то давал ссылку на англоязычные рекомендации, делал, не помогало ощутимо.

> 1 марта 2010 г. 19:09 пользователь Sergey Kobzar <sergey.kobzar@mail.ru> написал:
> Monday, March 1, 2010, 7:04:52 PM, Sergey wrote:

>> Monday, March 1, 2010, 6:34:41 PM, Богун wrote:

>>> Вы бы хоть конфигурацию железа написали и ядро.

>>> Раньше я никогда не сталкивался с особыми проблемами загрузки от io(в
>>> линах с 2001-го), но недавно досталась мне машинка, которая ощутимо
>>> тупит при нагрузке на диски.

>>> Я связываю это с AMD'шной архитектурой(до того всегда пользовался
>>> системами на базе интеловских процов). Ну вернее не столько с самим
>>> процом, сколько с матерью под него. Возможно это и не так, но
>>> полноценный тест провести сейчас не могу, нет "лишнего" железа.

>>> По опросу народа, подтвердились проблемы с IO подсистемой на матерях c
>>> nvidia чипом, но опять же это лишь гипотеза.

>> На Intel (Xeon) те же яйца.


>>> И на более свежее ядро перепозти сейчас не получится потому как дежат
>>> vmware-modules

>> VMware Server 2.х работает на > 2.6.27, но уродливое оно какое-то.


>>> Инфа по системе в аттаче.

>>> ЗЫ На боевых системах гента пректасно трудится, но там извините другое
>>> железо и как правило железные raid'ы.

>> На железных рэйдах дикие тормоза аналогично. LA при дисковой нагрузке
поднимается >>>6 на ядрах >2.6.19, в то время, как на 2.6.19 LA >2 не
>> наблюдается.

>>> ЗЫЫ Я не сторонних святых войн, говорю лишь то что знаю из своего опыта.

>> Аналогично


> Да, Linux стает буквой Z если на диск пишет одновременно неск.
> процессов. dd результата не даст. Запустите в VMware 3-4 виртуальных
> машины и сразу поймете о чем я  


Я уже ответил как я борюсь. Другого решения не нашел.

Вот еще по теме интересное сравнение 3-летней давности.

http://linux.derkeiler.com/Mailing-Lists/Kernel/2007-02/msg04044.html

Для меня результаты актуальны, разница даже увеличилась.

-- 
Sergey

Re: [gentoo-user-ru] Насущный вопрос о тормозах при интенсивном I/O

[Alex Efros]

Hi!

On Mon, Mar 01, 2010 at 08:21:26PM +0200, Охрименко Александр wrote:
> Главный вопрос: как бороться? Кому что помогло? В прошлой рассылке кто то
> давал ссылку на англоязычные рекомендации, делал, не помогало ощутимо.

Как я уже писал, мне помогла замена винта, причём пришлось перебрать
несколько моделей:
http://archives.gentoo.org/gentoo-user-ru/msg_cf2ef68ac992767a60b3c2c1f8e83455.xml

Баг явно очень сложный, поэтому его столько лет пофиксить не могут.

Если бы это просто был баг планировщика - он бы проявлялся на любом железе
(в крайней случае, на определённом диапазоне железа - напр. со скоростью
меньше определённой границы). На практике же на одном железе это баг есть,
на другом нет, но чётких и простых признаков, по которым можно было бы
определить на каком железе будет тормозить, а на каком нет - пока не нашли.

Ещё одна причина, по которой его сложно найти - в районе 2.6.19-го ядра
была сильно переписана вся эта подсистема ядра, поэтому найти какой-то
конкретный патч, после которого баг есть, а до которого его нет - нереально.

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

-- 
			WBR, Alex.

[gentoo-user-ru] Re[2]: [gentoo-user-ru] Насущный вопрос о тормозах при интенсивном I/O

[Sergey Kobzar]

Monday, March 1, 2010, 9:15:39 PM, Alex wrote:

> On Mon, Mar 01, 2010 at 08:21:26PM +0200, Охрименко Александр wrote:
>> Главный вопрос: как бороться? Кому что помогло? В прошлой рассылке кто то
>> давал ссылку на англоязычные рекомендации, делал, не помогало ощутимо.

> Как я уже писал, мне помогла замена винта, причём пришлось перебрать
> несколько моделей:
> http://archives.gentoo.org/gentoo-user-ru/msg_cf2ef68ac992767a60b3c2c1f8e83455.xml

> Баг явно очень сложный, поэтому его столько лет пофиксить не могут.

> Если бы это просто был баг планировщика - он бы проявлялся на любом железе
> (в крайней случае, на определённом диапазоне железа - напр. со скоростью
> меньше определённой границы). На практике же на одном железе это баг есть,
> на другом нет, но чётких и простых признаков, по которым можно было бы
> определить на каком железе будет тормозить, а на каком нет - пока не нашли.

Баг проявляется как на CFQ, так и на Deadline.

По железу - у меня практически на всех серверах подобное. Если
телодвижения не будут зря - могу дать спецификацию.


> Ещё одна причина, по которой его сложно найти - в районе 2.6.19-го ядра
> была сильно переписана вся эта подсистема ядра, поэтому найти какой-то
> конкретный патч, после которого баг есть, а до которого его нет - нереально.

> Поработав на новом винте несколько месяцев могу сказать, что баг, похоже,
> по-прежнему существует... но только напоминает он о себе сейчас крайне
> редко и скромно - вероятно, тогда, когда необычно много приложений
> начинает работать с винтом.

Именно.


> Но это случается так редко и длится так недолго, что можно сказать,
> что проблема решена.

Это наверно на десктопе? ;)


-- 
Sergey

Re: [gentoo-user-ru] Re[2]: [gentoo-user-ru] Насущный вопрос о тормозах при интенсивном I/O

[Alex Efros]

Hi!

On Mon, Mar 01, 2010 at 09:44:43PM +0200, Sergey Kobzar wrote:
> Баг проявляется как на CFQ, так и на Deadline.

Угу. И с любыми настройками планировщиков через sysctl.

> По железу - у меня практически на всех серверах подобное. Если
> телодвижения не будут зря - могу дать спецификацию.

На мой взгляд - не зря. Я уже предлагал пару раз собрать базу данных по
тормозящему и не тормозящему железу - это может сильно помочь и
разработчикам, и людям, которые готовы решить проблему сменой железа.

> > Но это случается так редко и длится так недолго, что можно сказать,
> > что проблема решена.
> Это наверно на десктопе? ;)

Угу. Что творится в этом смысле на моих серверах - я не знаю.
Вероятно, там баг не проявляется - иначе я, наверное, бы знал. ;)

Файлы гиговые там не копируются (точнее, копируются, но редко и только по
сети - бэкапы - так что скорость ограничена сетью и ssh), каких-либо
заметных тормозов в работе сетевых сервисов вроде веб-сервера и наших
скриптов я не замечал, MySQL вроде работает тоже нормально. В общем, баг
может и есть, но как это проверить и как определить насколько он мешает
работать серверам - не понятно.

В плане железа - сервера 'HP ProLiant DL140 G3', винты 'FB080C4080'.

-- 
			WBR, Alex.

[gentoo-user-ru] Re[2]: [gentoo-user-ru] Re[2]: [gentoo-user-ru] Насущный вопрос о тормозах при интенсивном I/O

[Sergey Kobzar]

Monday, March 1, 2010, 10:07:03 PM, Alex wrote:

> On Mon, Mar 01, 2010 at 09:44:43PM +0200, Sergey Kobzar wrote:
>> Баг проявляется как на CFQ, так и на Deadline.

> Угу. И с любыми настройками планировщиков через sysctl.

Настройки sysctl - до балды.

>> По железу - у меня практически на всех серверах подобное. Если
>> телодвижения не будут зря - могу дать спецификацию.

> На мой взгляд - не зря. Я уже предлагал пару раз собрать базу данных по
> тормозящему и не тормозящему железу - это может сильно помочь и
> разработчикам, и людям, которые готовы решить проблему сменой железа.

Это раз:

Intel(R) Xeon(TM) CPU 2.66GHz

00:00.0 Host bridge: Intel Corporation E7505 Memory Controller Hub (rev 03)
00:00.1 Class ff00: Intel Corporation E7505/E7205 Series RAS Controller (rev 03)
00:01.0 PCI bridge: Intel Corporation E7505/E7205 PCI-to-AGP Bridge (rev 03)
00:02.0 PCI bridge: Intel Corporation E7505 Hub Interface B PCI-to-PCI Bridge (rev 03)
00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 82)
00:1f.0 ISA bridge: Intel Corporation 82801DB/DBL (ICH4/ICH4-L) LPC Interface Bridge (rev 02)
00:1f.1 IDE interface: Intel Corporation 82801DB (ICH4) IDE Controller (rev 02)
00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 02)
00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 02)
01:00.0 VGA compatible controller: nVidia Corporation NV17 [GeForce4 MX 440] (rev a3)
02:1c.0 PIC: Intel Corporation 82870P2 P64H2 I/OxAPIC (rev 04)
02:1d.0 PCI bridge: Intel Corporation 82870P2 P64H2 Hub PCI Bridge (rev 04)
02:1e.0 PIC: Intel Corporation 82870P2 P64H2 I/OxAPIC (rev 04)
02:1f.0 PCI bridge: Intel Corporation 82870P2 P64H2 Hub PCI Bridge (rev 04)
03:01.0 RAID bus controller: 3ware Inc 7xxx/8xxx-series PATA/SATA-RAID (rev 01)
03:03.0 Ethernet controller: Intel Corporation 82545EM Gigabit Ethernet Controller (Copper) (rev 01)
04:01.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5701 Gigabit Ethernet (rev 15)


Это два:

Intel(R) Xeon(R) CPU 5140  @ 2.33GHz

00:00.0 Host bridge: Intel Corporation 5000P Chipset Memory Controller Hub (rev 92)
00:02.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x8 Port 2-3 (rev 92)
00:03.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x4 Port 3 (rev 92)
00:04.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x8 Port 4-5 (rev 92)
00:05.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x4 Port 5 (rev 92)
00:06.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x8 Port 6-7 (rev 92)
00:07.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x4 Port 7 (rev 92)
00:08.0 System peripheral: Intel Corporation 5000 Series Chipset DMA Engine (rev 92)
00:10.0 Host bridge: Intel Corporation 5000 Series Chipset FSB Registers (rev 92)
00:10.1 Host bridge: Intel Corporation 5000 Series Chipset FSB Registers (rev 92)
00:10.2 Host bridge: Intel Corporation 5000 Series Chipset FSB Registers (rev 92)
00:11.0 Host bridge: Intel Corporation 5000 Series Chipset Reserved Registers (rev 92)
00:13.0 Host bridge: Intel Corporation 5000 Series Chipset Reserved Registers (rev 92)
00:15.0 Host bridge: Intel Corporation 5000 Series Chipset FBD Registers (rev 92)
00:16.0 Host bridge: Intel Corporation 5000 Series Chipset FBD Registers (rev 92)
00:1c.0 PCI bridge: Intel Corporation 631xESB/632xESB/3100 Chipset PCI Express Root Port 1 (rev 09)
00:1d.0 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #1 (rev 09)
00:1d.1 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #2 (rev 09)
00:1d.2 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #3 (rev 09)
00:1d.3 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #4 (rev 09)
00:1d.7 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset EHCI USB2 Controller (rev 09)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev d9)
00:1f.0 ISA bridge: Intel Corporation 631xESB/632xESB/3100 Chipset LPC Interface Controller (rev 09)
00:1f.1 IDE interface: Intel Corporation 631xESB/632xESB IDE Controller (rev 09)
00:1f.3 SMBus: Intel Corporation 631xESB/632xESB/3100 Chipset SMBus Controller (rev 09)
01:00.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express Upstream Port (rev 01)
01:00.3 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express to PCI-X Bridge (rev 01)
02:00.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express Downstream Port E1 (rev 01)
02:02.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express Downstream Port E3 (rev 01)
04:00.0 Ethernet controller: Intel Corporation 80003ES2LAN Gigabit Ethernet Controller (Copper) (rev 01)
04:00.1 Ethernet controller: Intel Corporation 80003ES2LAN Gigabit Ethernet Controller (Copper) (rev 01)
0b:00.0 PCI bridge: Intel Corporation 41210 [Lanai] Serial to Parallel PCI Bridge (A-Segment Bridge) (rev 09)
0b:00.2 PCI bridge: Intel Corporation 41210 [Lanai] Serial to Parallel PCI Bridge (B-Segment Bridge) (rev 09)
0c:0c.0 RAID bus controller: 3ware Inc 9550SX SATA-II RAID PCI-X
0e:0c.0 VGA compatible controller: ATI Technologies Inc ES1000 (rev 02)


Вариации на тему разная модель чипсета, проца, кол-во ядер - итог
одинаков.

Могу сказать только везде платформа Intel (Xeon) + 3ware controller
(IDE / SATA / SAS).

Ядра после 2.6.19 - везде тормоза. После 2.6.30 немного лучше, но все
равно хреново.


>> > Но это случается так редко и длится так недолго, что можно сказать,
>> > что проблема решена.
>> Это наверно на десктопе? ;)

> Угу. Что творится в этом смысле на моих серверах - я не знаю.
> Вероятно, там баг не проявляется - иначе я, наверное, бы знал. ;)

> Файлы гиговые там не копируются (точнее, копируются, но редко и только по
> сети - бэкапы - так что скорость ограничена сетью и ssh), каких-либо
> заметных тормозов в работе сетевых сервисов вроде веб-сервера и наших
> скриптов я не замечал, MySQL вроде работает тоже нормально. В общем, баг
> может и есть, но как это проверить и как определить насколько он мешает
> работать серверам - не понятно.

Да всякие там мыльники, FTP, web - это не в счет. Половина данных
кэшируется. Интереснее когда или Samba или VMware с запущенными >2
виртуальными машинами.


> В плане железа - сервера 'HP ProLiant DL140 G3', винты 'FB080C4080'.


-- 
Sergey

[gentoo-user-ru] Re: Насущный вопрос о тормозах при интенсивном I/O

[spirit]

02.03.2010 02:07, Alex Efros пишет:
> На мой взгляд - не зря. Я уже предлагал пару раз собрать базу данных по
> тормозящему и не тормозящему железу - это может сильно помочь и
> разработчикам, и людям, которые готовы решить проблему сменой железа.

многим была бы интересна статистика.
И еще многие бы вложили свой вклад сбором статистики, если бы это было проще - запустить один скрипт
к примеру. который все посчитает и предоставил результаты, которые просто надо будет скопи пастить
на какой нить САЙТ., а не держать данные в рассылке или кернел баг репортах.

т.е. для гламура нужно две веши:
1. сайт, где будет удобно предоставлена статистика.
2. скрипт, который все делает за тебя :).

Re: [gentoo-user-ru] Re: Насущный вопрос о тормозах при интенсивном I/O

[Dmitry Pisarev]

spirit wrote:
> 02.03.2010 02:07, Alex Efros пишет:
>   
>> На мой взгляд - не зря. Я уже предлагал пару раз собрать базу данных по
>> тормозящему и не тормозящему железу - это может сильно помочь и
>> разработчикам, и людям, которые готовы решить проблему сменой железа.
>>     
>
> многим была бы интересна статистика.
> И еще многие бы вложили свой вклад сбором статистики, если бы это было проще - запустить один скрипт
> к примеру. который все посчитает и предоставил результаты, которые просто надо будет скопи пастить
> на какой нить САЙТ., а не держать данные в рассылке или кернел баг репортах.
>
> т.е. для гламура нужно две веши:
> 1. сайт, где будет удобно предоставлена статистика.
> 2. скрипт, который все делает за тебя :).
>
>   
нашел человека, который не прочь написать сайтег с гибкой выборкой. 
вроде не особо сложно.
с Вас (сообщества или Alex) - скрипт теста :)
вероятно пока не понятно как это будет развиваться, вопрос хостинга 
можно не поднимать. - повещу пока на себя.

[gentoo-user-ru] Re[2]: [gentoo-user-ru] Re: Насущный вопрос о тормозах при интенсивном I/O

[Sergey Kobzar]

Tuesday, March 2, 2010, 9:05:08 AM, Dmitry wrote:

> spirit wrote:
>> 02.03.2010 02:07, Alex Efros пишет:
>>   
>>> На мой взгляд - не зря. Я уже предлагал пару раз собрать базу данных по
>>> тормозящему и не тормозящему железу - это может сильно помочь и
>>> разработчикам, и людям, которые готовы решить проблему сменой железа.
>>>     
>>
>> многим была бы интересна статистика.
>> И еще многие бы вложили свой вклад сбором статистики, если бы это было проще - запустить один скрипт
>> к примеру. который все посчитает и предоставил результаты, которые просто надо будет скопи пастить
>> на какой нить САЙТ., а не держать данные в рассылке или кернел баг репортах.
>>
>> т.е. для гламура нужно две веши:
>> 1. сайт, где будет удобно предоставлена статистика.
>> 2. скрипт, который все делает за тебя :).
>>
>>   
> нашел человека, который не прочь написать сайтег с гибкой выборкой. 
> вроде не особо сложно.
> с Вас (сообщества или Alex) - скрипт теста :)
> вероятно пока не понятно как это будет развиваться, вопрос хостинга 
> можно не поднимать. - повещу пока на себя.


1. Я подозреваю что проблема не в железе, а именно в типе нагрузки на
   дисковую подсистему.

2. Соберем данные, а дальше?


-- 
Sergey

[gentoo-user-ru] Re: [gentoo-user-ru] Re[2]: [gentoo-user-ru] Re: Насущный вопрос о тормозах при интенсивном I/O

[Охрименко Александр]

[-- Attachment #1: Type: text/plain, Size: 245 bytes --]

Тормоза наблюдаются как мне кажется у 99%. Может там где то явный цикл в
миллиард циклов :) Засланный казачок вставил :)


-- 
Охрименко А.А.

[-- Attachment #2: Type: text/html, Size: 273 bytes --]

[gentoo-user-ru] Re: Насущный вопрос о тормозах при интенсивном I/O

[dev-random]

У меня на ноуте был 120G винт Samsung, тормозов не было. Проапгрейдил до
500G Seagate и начались тормоза.

[gentoo-user-ru] Re: [gentoo-user-ru] Re[2]: [gentoo-user-ru] Re: Насущный вопрос о тормозах при интенсивном I/O

[Dmitry Pisarev]

Sergey Kobzar wrote:
> Tuesday, March 2, 2010, 9:05:08 AM, Dmitry wrote:
>
>   
>> spirit wrote:
>>     
>>> 02.03.2010 02:07, Alex Efros пишет:
>>>   
>>>       
>>>> На мой взгляд - не зря. Я уже предлагал пару раз собрать базу данных по
>>>> тормозящему и не тормозящему железу - это может сильно помочь и
>>>> разработчикам, и людям, которые готовы решить проблему сменой железа.
>>>>     
>>>>         
>>> многим была бы интересна статистика.
>>> И еще многие бы вложили свой вклад сбором статистики, если бы это было проще - запустить один скрипт
>>> к примеру. который все посчитает и предоставил результаты, которые просто надо будет скопи пастить
>>> на какой нить САЙТ., а не держать данные в рассылке или кернел баг репортах.
>>>
>>> т.е. для гламура нужно две веши:
>>> 1. сайт, где будет удобно предоставлена статистика.
>>> 2. скрипт, который все делает за тебя :).
>>>
>>>   
>>>       
>> нашел человека, который не прочь написать сайтег с гибкой выборкой. 
>> вроде не особо сложно.
>> с Вас (сообщества или Alex) - скрипт теста :)
>> вероятно пока не понятно как это будет развиваться, вопрос хостинга 
>> можно не поднимать. - повещу пока на себя.
>>     
>
>
> 1. Я подозреваю что проблема не в железе, а именно в типе нагрузки на
>    дисковую подсистему.
>
> 2. Соберем данные, а дальше?
>
>
>   
а дальше надо как то дать почитать девелоперам ядра.. что бы им 
статистика понравилась :).
другой выхлоп как уже писали - смена железа по народной мудрости :)

Alex, может сразу списаться с ядерным девелопером, кто баг курирует, и 
спросить про жизнеспособность этой идеи?. Если согласен, то спишись ты.:)

[gentoo-user-ru] Re: [gentoo-user-ru] Re: [gentoo-user-ru] Re[2]: [gentoo-user-ru] Re: Насущный вопрос о тормозах при интенсивном I/O

[Sergey Kobzar]

Tuesday, March 2, 2010, 10:42:22 AM, Dmitry wrote:

>> 1. Я подозреваю что проблема не в железе, а именно в типе нагрузки на
>>    дисковую подсистему.
>>
>> 2. Соберем данные, а дальше?
>>
>>
>>   
> а дальше надо как то дать почитать девелоперам ядра.. что бы им 
> статистика понравилась :).
> другой выхлоп как уже писали - смена железа по народной мудрости :)

> Alex, может сразу списаться с ядерным девелопером, кто баг курирует, и
> спросить про жизнеспособность этой идеи?. Если согласен, то спишись ты.:)

Не знаю как на счет железа. У меня его предостаточно. Винты разные.
Контроллеры в основном 3ware. Баг вылазит везде.

Со своей стороны готов помочь. Лишь бы не в пустую было...

Действительно сначала надо связаться с kernel hacker который готов
помочь.


-- 
Sergey

Re: [gentoo-user-ru] Re: [gentoo-user-ru] Re[2]: [gentoo-user-ru] Re: Насущный вопрос о тормозах при интенсивном I/O

[Alex Efros]

Hi!

On Tue, Mar 02, 2010 at 02:42:22PM +0600, Dmitry Pisarev wrote:
> а дальше надо как то дать почитать девелоперам ядра.. что бы им 
> статистика понравилась :).
> другой выхлоп как уже писали - смена железа по народной мудрости :)
> 
> Alex, может сразу списаться с ядерным девелопером, кто баг курирует, и 
> спросить про жизнеспособность этой идеи?. Если согласен, то спишись ты.:)

Уже. Я писал об этом прямо в том баге ядра, и девелоперы мне тогда активно
отвечали, что-то обсуждали - так что они это предложение видели точно.
Но энтузиазм у них по этому поводу явно отсутствовал. Подозреваю, что их
мысли были примерно такие: "странная статистика, которая вообще не факт
что имеет отношение к делу, и с которой непонятно что вообще делать дальше...".
В общем, если статистику собрать самим, и по ней будут реально видны
какие-то зависимости, то с этим уже реально будет девелоперов дёргать.

По хорошему, чтобы от этой статистики была польза, нужен не только список
тормозящего железа, но и не тормозящего. И определить не тормозящее будет
не так просто - как уже верно пометили в этой ветке, по обычным серверам с
веб-сайтами практически нереально определить, тормозит он или нет. Так что
в статистику имеет смысл включать только рабочие станции, а из серверов
только что-то жёстко работающее с диском и с легко обнаруживаемыми
тормозами - вроде серверов vmware.

Что касается скрипта для сбора статистики - думаю, lshw более чем
достаточно. Тем более, что есть некоторые основания считать, что проблема
зависит не от всего возможного железа, а только от винта, и для начала
достаточно проверить эту теорию. Можно на каком-нить бесплатном
wiki-хостинге создать страничку со списками тормозящих и не тормозящих
винтов, и ссылками на детальные результаты lshw.

-- 
			WBR, Alex.

[gentoo-user-ru] Re[2]: [gentoo-user-ru] Re: [gentoo-user-ru] Re[2]: [gentoo-user-ru] Re: Насущный вопрос о тормозах при интенсивном I/O

[Sergey Kobzar]

Tuesday, March 2, 2010, 11:59:36 AM, Alex wrote:

> On Tue, Mar 02, 2010 at 02:42:22PM +0600, Dmitry Pisarev wrote:
>> а дальше надо как то дать почитать девелоперам ядра.. что бы им 
>> статистика понравилась :).
>> другой выхлоп как уже писали - смена железа по народной мудрости :)
>> 
>> Alex, может сразу списаться с ядерным девелопером, кто баг курирует, и 
>> спросить про жизнеспособность этой идеи?. Если согласен, то спишись ты.:)

> Уже. Я писал об этом прямо в том баге ядра, и девелоперы мне тогда активно
> отвечали, что-то обсуждали - так что они это предложение видели точно.
> Но энтузиазм у них по этому поводу явно отсутствовал. Подозреваю, что их
> мысли были примерно такие: "странная статистика, которая вообще не факт
> что имеет отношение к делу, и с которой непонятно что вообще делать дальше...".
> В общем, если статистику собрать самим, и по ней будут реально видны
> какие-то зависимости, то с этим уже реально будет девелоперов дёргать.

> По хорошему, чтобы от этой статистики была польза, нужен не только список
> тормозящего железа, но и не тормозящего. И определить не тормозящее будет
> не так просто - как уже верно пометили в этой ветке, по обычным серверам с
> веб-сайтами практически нереально определить, тормозит он или нет. Так что
> в статистику имеет смысл включать только рабочие станции, а из серверов
> только что-то жёстко работающее с диском и с легко обнаруживаемыми
> тормозами - вроде серверов vmware.

Думаю смогу найти штуки 3 сервера с VMware и новым ядром. На остальных
серверах ядро оставил 2.6.19. Железо идентичное. Можно будет заодно и
сравнить.


> Что касается скрипта для сбора статистики - думаю, lshw более чем
> достаточно. Тем более, что есть некоторые основания считать, что проблема
> зависит не от всего возможного железа, а только от винта, и для начала
> достаточно проверить эту теорию.

У меня Hitachi, WD, Seagate прицеплены к 3ware - везде картина
одинаковая.


> Можно на каком-нить бесплатном wiki-хостинге создать страничку со
> списками тормозящих и не тормозящих винтов, и ссылками на детальные
> результаты lshw.


-- 
Sergey

Re: [gentoo-user-ru] Re: [gentoo-user-ru] Re[2]: [gentoo-user-ru] Re: Насущный вопрос о тормозах при интенсивном I/O

[Богун Дмитрий]

В Втр, 02/03/2010 в 11:59 +0200, Alex Efros пишет:
> Что касается скрипта для сбора статистики - думаю, lshw более чем
> достаточно. 
А как lshw будет генерировать "характерную" и наиболее наглядную для
обсуждаемоей проблемы нагрузку на систему ввода/вывода?

> Тем более, что есть некоторые основания считать, что проблема
> зависит не от всего возможного железа, а только от винта, и для начала
> достаточно проверить эту теорию. 
А можно про эти "основания" подробнее?
Логичнее все же предположить, что проблема не на этапе SATA
conroller<=>hdd, а на этапе kernel<=>SATA controller или же в самой
архитектуре подсистемы ввода/вывода ядра. Ведь ядро общается не с
дисками, а с контроллером, который уже в свою очередь общается с
дисками.

> Можно на каком-нить бесплатном
> wiki-хостинге создать страничку со списками тормозящих и не тормозящих
> винтов, и ссылками на детальные результаты lshw.

[gentoo-user-ru] Re: [gentoo-user-ru] Re: [gentoo-user-ru] Re[2]: [gentoo-user-ru] Re: Насущный вопрос о тормозах при интенсивном I/O

[Alexander Tiurin]

2 марта 2010 г. 14:22 пользователь Богун Дмитрий  написал:
> В Втр, 02/03/2010 в 11:59 +0200, Alex Efros пишет:
>> Что касается скрипта для сбора статистики - думаю, lshw более чем
>> достаточно.
> А как lshw будет генерировать "характерную" и наиболее наглядную для
> обсуждаемоей проблемы нагрузку на систему ввода/вывода?
>

Для генерации нагрузки предется как-то определяться в виде
последовательности заранее договоренных действий.

Re: [gentoo-user-ru] Re: [gentoo-user-ru] Re: [gentoo-user-ru] Re[2]: [gentoo-user-ru] Re: Насущный вопрос о тормозах при интенсивном I/O

[Alex Efros]

Hi!

On Tue, Mar 02, 2010 at 06:26:09PM +0300, Alexander Tiurin wrote:
> >> Что касается скрипта для сбора статистики - думаю, lshw более чем
> >> достаточно.
> > А как lshw будет генерировать "характерную" и наиболее наглядную для
> > обсуждаемоей проблемы нагрузку на систему ввода/вывода?

lshw не генерирует нагрузку, он соберёт инфу по установленному железу

> Для генерации нагрузки предется как-то определяться в виде
> последовательности заранее договоренных действий.

В комментариях в багзилле ядра приводилось несколько вариантов генерации
нагрузки. Сложность ещё и в том, что там мешанина нескольких разных багов.
Часть этих багов более-менее пофиксили, поэтому многие отмечают улучшения
производительности на ядрах >=2.6.31. Но тот баг, который был у меня, пока
не отловили.

И этот баг можно протестировать достаточно просто: при копировании больших
файлов (желательно, объёмом на 1GB больше доступной RAM чтобы исключить
кеширование) чётко наблюдаются два эффекта - крайне низкая скорость и
высокий iowait (ну и тормозит интерфейс, конечно, но это сложно замерить в
тестах).

Соответственно, самый простой вариант теста - запуск dd на чтение, запись,
или чтение/запись. Ещё можно запустить несколько dd параллельно.

Пример:

    # hdparm -t /dev/sda
    
    /dev/sda:
     Timing buffered disk reads:  332 MB in  3.01 seconds = 110.45 MB/sec
    
    # dd if=/dev/zero of=test1 bs=1M count=5000
    5000+0 записей считано
    5000+0 записей написано
     скопировано 5242880000 байт (5.2 GB), 53.1426 c, 98.7 MB/c
    
    # dd if=test1 of=/dev/null bs=1M
    5000+0 записей считано
    5000+0 записей написано
     скопировано 5242880000 байт (5.2 GB), 49.6235 c, 106 MB/c
    
    # dd if=test1 of=test2 bs=1M
    5000+0 записей считано
    5000+0 записей написано
     скопировано 5242880000 байт (5.2 GB), 117.685 c, 44.5 MB/c

На старом винте (с тормозами), у меня hdparm выдавал примерно то же самое
(80-100 MB/sec), а вот dd выдавал максимум 20 MB/sec, а иногда и 3 MB/sec
(причём это в одну сторону, чтение либо запись, а не копирование!).

Что касается высокого iowait, то в моём случае он не изменился - `vmstat 1`
по-прежнему показывает iowait порядка 40-60%, что на старом винте с
тормозами что на новом без тормозов. А вот интерфейс на новом винте не
тормозит, так что, получается, высокий iowait это ещё не показатель
тормозов интерфейса.

В результате, в моём случае есть два чётких критерия: скорость работы dd и
тормоза интерфейса. Как измерить второе не ясно, зато первое проверяется
элементарно. Я бы предложил для начала ограничиться сбором статистики по
железу только у тех, у кого наблюдаются полностью идентичные моим симптомы - 
т.е. тормоза dd - чтобы попытаться изолировать один баг.

-- 
			WBR, Alex.

[gentoo-user-ru] Re[2]: [gentoo-user-ru] Re: [gentoo-user-ru] Re: [gentoo-user-ru] Re[2]: [gentoo-user-ru] Re: Насущный вопрос о тормозах при интенсивном I/O

[Sergey Kobzar]

Могу добавить, что если запускаю один dd - все ОК, скорость >150M
доходит. Как только на диск пишет несколько процессов, суммартная
скорость не превышает 40М.

Tuesday, March 2, 2010, 9:20:42 PM, Alex wrote:

> Hi!

> On Tue, Mar 02, 2010 at 06:26:09PM +0300, Alexander Tiurin wrote:
>> >> Что касается скрипта для сбора статистики - думаю, lshw более чем
>> >> достаточно.
>> > А как lshw будет генерировать "характерную" и наиболее наглядную для
>> > обсуждаемоей проблемы нагрузку на систему ввода/вывода?

> lshw не генерирует нагрузку, он соберёт инфу по установленному железу

>> Для генерации нагрузки предется как-то определяться в виде
>> последовательности заранее договоренных действий.

> В комментариях в багзилле ядра приводилось несколько вариантов генерации
> нагрузки. Сложность ещё и в том, что там мешанина нескольких разных багов.
> Часть этих багов более-менее пофиксили, поэтому многие отмечают улучшения
> производительности на ядрах >=2.6.31. Но тот баг, который был у меня, пока
> не отловили.

> И этот баг можно протестировать достаточно просто: при копировании больших
> файлов (желательно, объёмом на 1GB больше доступной RAM чтобы исключить
> кеширование) чётко наблюдаются два эффекта - крайне низкая скорость и
> высокий iowait (ну и тормозит интерфейс, конечно, но это сложно замерить в
> тестах).

> Соответственно, самый простой вариант теста - запуск dd на чтение, запись,
> или чтение/запись. Ещё можно запустить несколько dd параллельно.

> Пример:

>     # hdparm -t /dev/sda
>     
>     /dev/sda:
>      Timing buffered disk reads:  332 MB in  3.01 seconds = 110.45 MB/sec
>     
>     # dd if=/dev/zero of=test1 bs=1M count=5000
>     5000+0 записей считано
>     5000+0 записей написано
>      скопировано 5242880000 байт (5.2 GB), 53.1426 c, 98.7 MB/c
>     
>     # dd if=test1 of=/dev/null bs=1M
>     5000+0 записей считано
>     5000+0 записей написано
>      скопировано 5242880000 байт (5.2 GB), 49.6235 c, 106 MB/c
>     
>     # dd if=test1 of=test2 bs=1M
>     5000+0 записей считано
>     5000+0 записей написано
>      скопировано 5242880000 байт (5.2 GB), 117.685 c, 44.5 MB/c

> На старом винте (с тормозами), у меня hdparm выдавал примерно то же самое
> (80-100 MB/sec), а вот dd выдавал максимум 20 MB/sec, а иногда и 3 MB/sec
> (причём это в одну сторону, чтение либо запись, а не копирование!).

> Что касается высокого iowait, то в моём случае он не изменился - `vmstat 1`
> по-прежнему показывает iowait порядка 40-60%, что на старом винте с
> тормозами что на новом без тормозов. А вот интерфейс на новом винте не
> тормозит, так что, получается, высокий iowait это ещё не показатель
> тормозов интерфейса.

> В результате, в моём случае есть два чётких критерия: скорость работы dd и
> тормоза интерфейса. Как измерить второе не ясно, зато первое проверяется
> элементарно. Я бы предложил для начала ограничиться сбором статистики по
> железу только у тех, у кого наблюдаются полностью идентичные моим симптомы -
> т.е. тормоза dd - чтобы попытаться изолировать один баг.




-- 
Sergey

Re: [gentoo-user-ru] Re[2]: [gentoo-user-ru] Re: [gentoo-user-ru] Re: [gentoo-user-ru] Re[2]: [gentoo-user-ru] Re: Насущный вопрос о тормозах при интенсивном I/O

[Alex Efros]

Hi!

On Tue, Mar 02, 2010 at 09:59:21PM +0200, Sergey Kobzar wrote:
> Могу добавить, что если запускаю один dd - все ОК, скорость >150M
> доходит. Как только на диск пишет несколько процессов, суммартная
> скорость не превышает 40М.

У меня суммарная скорость равна скорости одного dd:

home ~ # for i in 1 2 3; do dd if=/dev/zero of=test$i bs=1M count=5000 & done
[1] 6944
[2] 6945
[3] 6946
5000+0 записей считано
5000+0 записей написано
 скопировано 5242880000 байт (5.2 GB), 156.632 c, 33.5 MB/c
5000+0 записей считано
5000+0 записей написано
 скопировано 5242880000 байт (5.2 GB), 164.044 c, 32.0 MB/c
5000+0 записей считано
5000+0 записей написано
 скопировано 5242880000 байт (5.2 GB), 165.514 c, 31.7 MB/c
[1]   Done                    dd if=/dev/zero of=test$i bs=1M count=5000
[2]-  Done                    dd if=/dev/zero of=test$i bs=1M count=5000
[3]+  Done                    dd if=/dev/zero of=test$i bs=1M count=5000

-- 
			WBR, Alex.

[gentoo-user-ru] Re[2]: [gentoo-user-ru] Re[2]: [gentoo-user-ru] Re: [gentoo-user-ru] Re: [gentoo-user-ru] Re[2]: [gentoo-user-ru] Re: Насущный вопрос о тормозах при интенсивном I/O

[Sergey Kobzar]

Tuesday, March 2, 2010, 10:07:42 PM, Alex wrote:

> Hi!

> On Tue, Mar 02, 2010 at 09:59:21PM +0200, Sergey Kobzar wrote:
>> Могу добавить, что если запускаю один dd - все ОК, скорость >150M
>> доходит. Как только на диск пишет несколько процессов, суммартная
>> скорость не превышает 40М.

> У меня суммарная скорость равна скорости одного dd:

> home ~ # for i in 1 2 3; do dd if=/dev/zero of=test$i bs=1M count=5000 & done
> [1] 6944
> [2] 6945
> [3] 6946
> 5000+0 записей считано
> 5000+0 записей написано
>  скопировано 5242880000 байт (5.2 GB), 156.632 c, 33.5 MB/c
> 5000+0 записей считано
> 5000+0 записей написано
>  скопировано 5242880000 байт (5.2 GB), 164.044 c, 32.0 MB/c
> 5000+0 записей считано
> 5000+0 записей написано
>  скопировано 5242880000 байт (5.2 GB), 165.514 c, 31.7 MB/c
> [1]   Done                    dd if=/dev/zero of=test$i bs=1M count=5000
> [2]-  Done                    dd if=/dev/zero of=test$i bs=1M count=5000
> [3]+  Done                    dd if=/dev/zero of=test$i bs=1M count=5000


Я даже и не знаю как чистые тесты провести. В идеале - запустить dd в
несколько потоков на ядре <=2.6.19, и замерять суммартную скорость,
потом перепрыгнуть на 2.6.31 ядро и проделать то же самое. Но на
боевых серверах я такое делать не могу, тем более что 2.6.19 если мне
не изменяет память не компилится на gcc >4.1 (кажется).

-- 
Sergey

[gentoo-user-ru] Re: [gentoo-user-ru] Re: [gentoo-user-ru] Re: [gentoo-user-ru] Re[2]: [gentoo-user-ru] Re: Насущный вопрос о тормозах при интенсивном I/O

[Pavel Labushev]

03.03.2010 02:20, Alex Efros пишет:

> И этот баг можно протестировать достаточно просто: при копировании больших
> файлов (желательно, объёмом на 1GB больше доступной RAM чтобы исключить
> кеширование) чётко наблюдаются два эффекта - крайне низкая скорость и
> высокий iowait (ну и тормозит интерфейс, конечно, но это сложно замерить в
> тестах).

На счёт тормозов интерфейса: не наблюдаю их у себя после того, как после
2.6.30 перешёл на групповое планирование в CFS (не CFQ) между cgroups.
Где связь - не понятно, но она, похоже, есть. С тех пор тормозов
интерфейса не наблюдаю ни при компиляции, ни при emerge-webrsync, ни при
работе transmission (демон, тоже в группе system) - всё это на
сигейтовском 320-тнике, любой ввод-вывод на котором раньше безбожно
тормозил иксы.

Что сделал:

# mount | grep cpu
none on /cgroup/cpu type cgroup (rw,cpu)

В /cgroup/cpu созданы две директории групп: system и user

На старте системы в user/tasks записываются pid'ы Xorg и
дисплей-менеджера, system/tasks - все остальные.

В .bash_profile root'а добавил:
echo $$ > /cgroup/cpu/system/tasks
Чтобы по su -l шелл и его потомки, включая emerge, попадали в группу system.

PS
Кстати, на ядрах с grsec и включённым kernel.grsecurity.chroot_findtask
могут быть аналогичные тормоза при высокой активности процессов в
chroot'ах (при компиляции, например), но это уже связано с блокировками
на планирование внутри ядра во время проверок IPC, а не с глюками i/o. Я
в таких случаях либо отключаю chroot_findtask, либо отказываюсь от
чрутования в пользу RBAC.

[gentoo-user-ru] Re: [gentoo-user-ru] Re: [gentoo-user-ru] Re: [gentoo-user-ru] Re: [gentoo-user-ru] Re[2]: [gentoo-user-ru] Re: Насущный вопрос о тормозах при интенсивном I/O

[Охрименко Александр]

[-- Attachment #1: Type: text/plain, Size: 2883 bytes --]

А может вы как то подробнее опишите свои действия? :) Не все такие профи
чтобы понять, а какой то выход найти хочется.

3 марта 2010 г. 0:20 пользователь Pavel Labushev <p.labushev@gmail.com>написал:

> 03.03.2010 02:20, Alex Efros пишет:
>
> > И этот баг можно протестировать достаточно просто: при копировании
> больших
> > файлов (желательно, объёмом на 1GB больше доступной RAM чтобы исключить
> > кеширование) чётко наблюдаются два эффекта - крайне низкая скорость и
> > высокий iowait (ну и тормозит интерфейс, конечно, но это сложно замерить
> в
> > тестах).
>
> На счёт тормозов интерфейса: не наблюдаю их у себя после того, как после
> 2.6.30 перешёл на групповое планирование в CFS (не CFQ) между cgroups.
> Где связь - не понятно, но она, похоже, есть. С тех пор тормозов
> интерфейса не наблюдаю ни при компиляции, ни при emerge-webrsync, ни при
> работе transmission (демон, тоже в группе system) - всё это на
> сигейтовском 320-тнике, любой ввод-вывод на котором раньше безбожно
> тормозил иксы.
>
> Что сделал:
>
> # mount | grep cpu
> none on /cgroup/cpu type cgroup (rw,cpu)
>
> В /cgroup/cpu созданы две директории групп: system и user
>
> На старте системы в user/tasks записываются pid'ы Xorg и
> дисплей-менеджера, system/tasks - все остальные.
>
> В .bash_profile root'а добавил:
> echo $$ > /cgroup/cpu/system/tasks
> Чтобы по su -l шелл и его потомки, включая emerge, попадали в группу
> system.
>
> PS
> Кстати, на ядрах с grsec и включённым kernel.grsecurity.chroot_findtask
> могут быть аналогичные тормоза при высокой активности процессов в
> chroot'ах (при компиляции, например), но это уже связано с блокировками
> на планирование внутри ядра во время проверок IPC, а не с глюками i/o. Я
> в таких случаях либо отключаю chroot_findtask, либо отказываюсь от
> чрутования в пользу RBAC.
>
>


-- 
Охрименко А.А.

[-- Attachment #2: Type: text/html, Size: 3295 bytes --]

[gentoo-user-ru] Re: [gentoo-user-ru] Re: [gentoo-user-ru] Re: [gentoo-user-ru] Re: [gentoo-user-ru] Re: [gentoo-user-ru] Re[2]: [gentoo-user-ru] Re: Насущный вопрос о тормозах при интенсивном I/O

[Pavel Labushev]

12.03.2010 04:05, Охрименко Александр пишет:
> А может вы как то подробнее опишите свои действия? :) Не все такие профи
> чтобы понять, а какой то выход найти хочется.

Не профи по гуглению? :) А если серьёзно, сегодня проверил отзывчивость
иксов во время работы emerge-webrsync, без группового планирования (все
процессы были в корневой cgroup), и разницы не заметил. Тормозов не
было, а значит, они исчезли по другой причине. Возможно, дело было в
смене ядра на более свежее или в пересборке без какой-либо лишней опции
(периодически отключаю, что не понадобилось). Сейчас у меня
2.6.32.9-grseс. Думаю, с ванильным 2.6.32.х та же ситуация. Попробуйте
его, вдруг поможет.

Изначально я включал групповое планирование, чтобы ослабить влияние
интенсивных вычислений в фоне на отзывчивость иксов, просмотр фильмов и
т.п.. С этим оно справилось, даже в таком примитивном виде (всего две
группы).

Ядро должно быть собрано с CONFIG_GROUP_SCHED и CONFIG_CGROUP_SCHED. Дальше:

1. mkdir -m 700 /cgroup /cgroup/cpu

2. В fstab добавить:
none /cgroup/cpu cgroup cpu

3. В /etc/conf.d/local:
local_start() {
  if ( mountpoint -q /cgroup/cpu ); then
    [ -d /cgroup/cpu/system ] || mkdir /cgroup/cpu/system
    ebegin "Setting up system cpu cgroup"
    for N in 1 2 3; do
      for PROC in $(cat /cgroup/cpu/tasks); do
        echo $PROC > /cgroup/cpu/system/tasks 2>/dev/null
      done
    done
    eend
    [ -d /cgroup/cpu/user ] || mkdir /cgroup/cpu/user
    ebegin "Setting up user cgroup"
    echo $(pgrep -f /usr/bin/slim) > /cgroup/cpu/user/tasks 2>/dev/null
    echo $(pgrep -f /usr/bin/Xorg) > /cgroup/cpu/user/tasks 2>/dev/null
    eend
  fi
  return 0
}

4. В /root/.bash_profile:
echo $$ > /cgroup/cpu/system/tasks

5. rc-update add local default

6. Запустить local, перезапустить xdm, и вроде всё.

[gentoo-user-ru] Re: [gentoo-user-ru] Re: [gentoo-user-ru] Re[2]: [gentoo-user-ru] Re: Насущный вопрос о тормозах при интенсивном I/O

[Охрименко Александр]

[-- Attachment #1: Type: text/plain, Size: 500 bytes --]

У меня дома машина мощная, на Intel E8600, тормозит сходу на элементарном
eix-sync -W. А видно очень просто, запускаю iotop. И там сразу видно что
процесс записи типа reiserfs, tarsync занимает 99% IO. Не вкурсе куда лезет
iotop, но может можно где то в /proc/... раздобыть статистику можно.


-- 
Охрименко А.А.

[-- Attachment #2: Type: text/html, Size: 529 bytes --]

Re: [gentoo-user-ru] Насущный вопрос о тормозах при интенсивном I/O

[Andrew A. Sabitov]

> редко и скромно - вероятно, тогда, когда необычно много приложений
> начинает работать с винтом. Но это случается так редко и длится так
> недолго, что можно сказать, что проблема решена.

Применительно к Вашей системе, я так понимаю? :)

HP DL 360G4p на нем сквид, через который проходит до 80Гб трафика в  
сутки,(понятное дело, что 90% идут за 8 часов рабочего времени) + LAMP  
+ еще кое-что по-мелочи.

Я был вынужден насовать мешок памяти и сказать сквиду, чтобы он на  
диск ваапще не лез.

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

[gentoo-user-ru] Re: [gentoo-user-ru] Насущный вопрос о тормозах при интенсивном I/O

[Охрименко Александр]

[-- Attachment #1: Type: text/plain, Size: 4076 bytes --]

Я смотрю в портеже самая давняя версия 2.6.16-r13. Не зря?
OpenSuSe актуальное ядро - 2.6.25.20. Вроде не тормозит.
Еще вот в связи с различным проявлением интересно, а на 64-bit тоже такая
проблема есть?

У меня железо разное, есть древнее, есть поновее. Везде тормозит.
Конфигурация 1:
Материнка: P5GL-MX
Проц: Intel(R) Celeron(R) CPU 2.53GHz
Диск: SAMSUNG SP0411N
hdparm -T /dev/sda
 Timing cached reads:   1158 MB in  2.00 seconds = 578.58 MB/sec
hdparm -t /dev/sda
 Timing buffered disk reads:   76 MB in  3.00 seconds =  25.31 MB/sec
Конфигурация 2:
Материнка: 45CMX
Проц:Intel(R) Pentium(R) Dual  CPU  E2180  @ 2.00GHz
Диск: SAMSUNG HD161HJ
hdparm -T /dev/sda
 Timing cached reads:   1582 MB in  2.00 seconds = 790.39 MB/sec
hdparm -t /dev/sda
 Timing buffered disk reads:  196 MB in  3.01 seconds =  65.19 MB/sec

на первой ядро Linux 2.6.32-gentoo-r3
на второй Linux 2.6.31-gentoo-r10



1 марта 2010 г. 18:34 пользователь Богун Дмитрий
<vugluskr@vugluskr.org.ua>написал:

> В Пнд, 01/03/2010 в 18:00 +0200, Охрименко Александр пишет:
> > Подскажите пожалуйста коллеги, кто нибудь использует Gentoo в
> > производственных целях? Я имею ввиду что делать с тормозами при i/o?
> > Т.е. в моем понимании Linux (Gentoo) должна позволять использовать
> > возможности железа на 100%, а я получаю дико тормозную систему,
> > вместо которой винда быстрее бы работала :( Кто как борется с этой
> > проблемой (кроме покупки новых HDD, SCSI и т.д.) ? Разработчики ядра
> > что нибудь чешут себе в поисках где они допустили ошибку, неужели
> > никто не может отЛАЖИвать этот процесс? Это проблема всех последних
> > ядер
> > всех линуксов или только Gentoo?
> >
> > наболело....
> Вы бы хоть конфигурацию железа написали и ядро.
>
> Раньше я никогда не сталкивался с особыми проблемами загрузки от io(в
> линах с 2001-го), но недавно досталась мне машинка, которая ощутимо
> тупит при нагрузке на диски.
>
> Я связываю это с AMD'шной архитектурой(до того всегда пользовался
> системами на базе интеловских процов). Ну вернее не столько с самим
> процом, сколько с матерью под него. Возможно это и не так, но
> полноценный тест провести сейчас не могу, нет "лишнего" железа.
>
> По опросу народа, подтвердились проблемы с IO подсистемой на матерях c
> nvidia чипом, но опять же это лишь гипотеза.
>
> И на более свежее ядро перепозти сейчас не получится потому как дежат
> vmware-modules
>
> Инфа по системе в аттаче.
>
> ЗЫ На боевых системах гента пректасно трудится, но там извините другое
> железо и как правило железные raid'ы.
> ЗЫЫ Я не сторонних святых войн, говорю лишь то что знаю из своего опыта.
>



-- 
Охрименко А.А.

[-- Attachment #2: Type: text/html, Size: 4633 bytes --]

[gentoo-user-ru] Re: [gentoo-user-ru] Насущный вопрос о тормозах при интенсивном I/O

[Aleksandr Dezhin]

[-- Attachment #1: Type: text/plain, Size: 1390 bytes --]

1 марта 2010 г. 19:00 пользователь Охрименко Александр <
a.a.okhrimenko@gmail.com> написал:

> Подскажите пожалуйста коллеги, кто нибудь использует Gentoo в
> производственных целях? Я имею ввиду что делать с тормозами при i/o?
> Т.е. в моем понимании Linux (Gentoo) должна позволять использовать
> возможности железа на 100%, а я получаю дико тормозную систему,
> вместо которой винда быстрее бы работала :( Кто как борется с этой
> проблемой (кроме покупки новых HDD, SCSI и т.д.) ? Разработчики ядра
> что нибудь чешут себе в поисках где они допустили ошибку, неужели никто не
> может отЛАЖИвать этот процесс? Это проблема всех последних ядер
> всех линуксов или только Gentoo?
>
> наболело....
>
> --
> Охрименко А.А.
>

Попробовал перебраться с 2.6.30 на 2.6.33 - по первым субъективным
впечатлениям помогает очень сильно.

[-- Attachment #2: Type: text/html, Size: 1698 bytes --]

Re: [gentoo-user-ru] Насущный вопрос о тормозах при интенсивном I/O

[Геннадий Цой]

Надо Ж какой трэд пропустил!

Было ощущение, что в gentoo-user-ru только десктоп-юзеры, а тут вопрос про "производственные цели". :-)

Я без иронии. На самом деле рад такому повороту.

Если кто-то еще "жив" по этой теме, тому простые вопросы:

1. Вы сисадмины или где? ;-)
2. Почему все вопросы о железе и/или операционке, и ни одного о приложениях, которые на них живут?
3. Вы хором "подтверждаете" тормоза I/O на разном железе, а при этом вы проверяли один и тот же софт?
4. Т.е. вы уверены, что софт прекрасно живший на .19 представляет из себя то же самое, что вы ставите на .30?
5. Т.е. ваши коллеги-прогаммисты тупо "простаивают", и все это время ничего не поменяли в приложениях?
6. И при этом, они "давят" на вас, что все тормозит, а раньше все прекрасно "летало"?
7. В ваших базах данных, как было несколько сотен/тысяч записей, так и осталось?
8. Думаю хватит :-)


ЗЫ:
Не обещаю, что на все последующие вопросы отвечу (если таковые последуют),
но очень хотелось бы услышать от ищущих, хотя бы несколько ответов на свой первый и главный вопрос:
- почему никто не говорит о приложениях/сервисах, а в говорят только о железе/операционке?

ЗЗЫ:
Все сказанное относится только к админам серверов.
А если у кого-то тормозят Х-ы или KDE, тому "в руки" gentoo.org, google, man, либо тупо апгрейд железа или даунгрейд софта. ))

ЗЗЗЫ:
Если честно, все сообщения читать не осилил, и мог что-то упустить, но впечатление у меня такое, как описал в "вопросах".

С уважением,
BlaCat.

22.03.2010, в 3:02, Aleksandr Dezhin написал(а):

> 1 марта 2010 г. 19:00 пользователь Охрименко Александр <
> a.a.okhrimenko@gmail.com> написал:
> 
>> Подскажите пожалуйста коллеги, кто нибудь использует Gentoo в
>> производственных целях? Я имею ввиду что делать с тормозами при i/o?
>> Т.е. в моем понимании Linux (Gentoo) должна позволять использовать
>> возможности железа на 100%, а я получаю дико тормозную систему,
>> вместо которой винда быстрее бы работала :( Кто как борется с этой
>> проблемой (кроме покупки новых HDD, SCSI и т.д.) ? Разработчики ядра
>> что нибудь чешут себе в поисках где они допустили ошибку, неужели никто не
>> может отЛАЖИвать этот процесс? Это проблема всех последних ядер
>> всех линуксов или только Gentoo?
>> 
>> наболело....
>> 
>> --
>> Охрименко А.А.
>> 
> 
> Попробовал перебраться с 2.6.30 на 2.6.33 - по первым субъективным
> впечатлениям помогает очень сильно.

Re: [gentoo-user-ru] Насущный вопрос о тормозах при интенсивном I/O

[Andrew A. Sabitov]

Геннадий, у меня к Вам ровно один встречный вопрос:

1 Почему Вы считаете, что остальные глупее Вас?

И ответ на все Ваши вопросы: почему когда я на актуальной системе  
перебучаюсь в .18 у меня нет проседаний в производительности, но как  
только я возвращаюсь обратно в .31 они появляются! У меня от этого  
что, версия симанки меняется, или кутим другой возникает???



Quoting Геннадий Цой <gvtsoy@gmail.com>:

> Надо Ж какой трэд пропустил!
>
> Было ощущение, что в gentoo-user-ru только десктоп-юзеры, а тут  
> вопрос про "производственные цели". :-)
>
> Я без иронии. На самом деле рад такому повороту.
>
> Если кто-то еще "жив" по этой теме, тому простые вопросы:
>
> 1. Вы сисадмины или где? ;-)
> 2. Почему все вопросы о железе и/или операционке, и ни одного о  
> приложениях, которые на них живут?
> 3. Вы хором "подтверждаете" тормоза I/O на разном железе, а при этом  
> вы проверяли один и тот же софт?
> 4. Т.е. вы уверены, что софт прекрасно живший на .19 представляет из  
> себя то же самое, что вы ставите на .30?
> 5. Т.е. ваши коллеги-прогаммисты тупо "простаивают", и все это время  
> ничего не поменяли в приложениях?
> 6. И при этом, они "давят" на вас, что все тормозит, а раньше все  
> прекрасно "летало"?
> 7. В ваших базах данных, как было несколько сотен/тысяч записей, так  
> и осталось?
> 8. Думаю хватит :-)
>
>
> ЗЫ:
> Не обещаю, что на все последующие вопросы отвечу (если таковые последуют),
> но очень хотелось бы услышать от ищущих, хотя бы несколько ответов  
> на свой первый и главный вопрос:
> - почему никто не говорит о приложениях/сервисах, а в говорят только  
> о железе/операционке?
>
> ЗЗЫ:
> Все сказанное относится только к админам серверов.
> А если у кого-то тормозят Х-ы или KDE, тому "в руки" gentoo.org,  
> google, man, либо тупо апгрейд железа или даунгрейд софта. ))
>
> ЗЗЗЫ:
> Если честно, все сообщения читать не осилил, и мог что-то упустить,  
> но впечатление у меня такое, как описал в "вопросах".
>
> С уважением,
> BlaCat.
>
> 22.03.2010, в 3:02, Aleksandr Dezhin написал(а):
>
>> 1 марта 2010 г. 19:00 пользователь Охрименко Александр <
>> a.a.okhrimenko@gmail.com> написал:
>>
>>> Подскажите пожалуйста коллеги, кто нибудь использует Gentoo в
>>> производственных целях? Я имею ввиду что делать с тормозами при i/o?
>>> Т.е. в моем понимании Linux (Gentoo) должна позволять использовать
>>> возможности железа на 100%, а я получаю дико тормозную систему,
>>> вместо которой винда быстрее бы работала :( Кто как борется с этой
>>> проблемой (кроме покупки новых HDD, SCSI и т.д.) ? Разработчики ядра
>>> что нибудь чешут себе в поисках где они допустили ошибку, неужели никто не
>>> может отЛАЖИвать этот процесс? Это проблема всех последних ядер
>>> всех линуксов или только Gentoo?
>>>
>>> наболело....
>>>
>>> --
>>> Охрименко А.А.
>>>
>>
>> Попробовал перебраться с 2.6.30 на 2.6.33 - по первым субъективным
>> впечатлениям помогает очень сильно.
>
>



----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

[gentoo-user-ru] Re: [gentoo-user-ru] Насущный вопрос о тормозах при интенсивном I/O

[Охрименко Александр]

[-- Attachment #1: Type: text/plain, Size: 461 bytes --]

Если когда нибудь эта проблема будет устранена, напишите пожалуйста сюда, в
рассылку. На данный момент не вижу возможности использования Gentoo в
продакшене, оставаясь с актуальным ядром. Перехожу на S.u.S.e., там ничего
не тормозит и обновления регулярные...

[-- Attachment #2: Type: text/html, Size: 465 bytes --]

Re: [gentoo-user-ru] Re: [gentoo-user-ru] Насущный вопрос о тормозах при интенсивном I/O

[Andrew A. Sabitov]

Quoting Охрименко Александр <a.a.okhrimenko@gmail.com>:

> Если когда нибудь эта проблема будет устранена, напишите пожалуйста сюда, в
> рассылку. На данный момент не вижу возможности использования Gentoo в
> продакшене, оставаясь с актуальным ядром. Перехожу на S.u.S.e., там ничего
> не тормозит и обновления регулярные...
>

Ну, не знаю, поможет это общественности или как, но я для себя открыл
CONFIG_TASK_IO_ACCOUNTING и CONFIG_TASK_DELAY_ACCT. После отключения  
этих опций и пересборки ядра жизнь стала веселей.

Work for me :)

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Re: [gentoo-user-ru] Re: [gentoo-user-ru] Насущный вопрос о тормозах при интенсивном I/O

[Sergey Kobzar]

On 03/29/10 10:05, Andrew A. Sabitov wrote:
> Quoting Охрименко Александр <a.a.okhrimenko@gmail.com>:
>
>> Если когда нибудь эта проблема будет устранена, напишите пожалуйста
>> сюда, в
>> рассылку. На данный момент не вижу возможности использования Gentoo в
>> продакшене, оставаясь с актуальным ядром. Перехожу на S.u.S.e., там
>> ничего
>> не тормозит и обновления регулярные...
>>
>
> Ну, не знаю, поможет это общественности или как, но я для себя открыл
> CONFIG_TASK_IO_ACCOUNTING и CONFIG_TASK_DELAY_ACCT. После отключения
> этих опций и пересборки ядра жизнь стала веселей.
>
> Work for me :)

У меня эти опции отключены изначально были - безрезультатно.

[gentoo-user-ru] Re: [gentoo-user-ru] Re: [gentoo-user-ru] Насущный вопрос о тормозах при интенсивном I/O

[Охрименко Александр]

[-- Attachment #1: Type: text/plain, Size: 1520 bytes --]

Пробовал вариант Pavel Labushev, что то поменялось по субъективным
ощущениям, но все равно тормоза присутствовали, мышь дергалась в KDE.

CONFIG_TASK_IO_ACCOUNTING и CONFIG_TASK_DELAY_ACCT убрал, ничего не
поменялось. Но я тут заметил что у меня часть системы в своп влезла,
попробую добавить памяти, если у нас она есть, может что то изменится.

В SuSe ядре патч какой то есть, мне не удалось посмотреть что он исправляет.
По умолчанию ставится ядро с PAE:
Сведения - пакет kernel-pae:

Репозитарий: Updates for 11.0
Имя: kernel-pae
Версия: 2.6.25.20-0.7
Арх: i586
Производитель: SUSE LINUX Products GmbH, Nuernberg, Germany
Установлен: Да
Состояние: актуален
Размер после установки: 99,2 M
Сводка: Kernel with PAE Support
Описание:
This kernel supports up to 64GB of main memory. It requires Physical
Addressing Extensions (PAE), which were introduced with the Pentium Pro
processor.

На днях вышел OpenSuSe 11.3 может там еще более новое ядро, у меня под
оракловую базу Express Edition установлен 11.0.


-- 
Охрименко А.А.

[-- Attachment #2: Type: text/html, Size: 1619 bytes --]

[gentoo-user-ru] Re: [gentoo-user-ru] Re: [gentoo-user-ru] Насущный вопрос о тормозах при интенсивном I/O

[Охрименко Александр]

[-- Attachment #1: Type: text/plain, Size: 154 bytes --]

C отключенными  CONFIG_TASK_IO_ACCOUNTING и CONFIG_TASK_DELAY_ACCT перестал
работать iotop...

-- 
Охрименко А.А.

[-- Attachment #2: Type: text/html, Size: 181 bytes --]

[gentoo-user-ru] Re: [gentoo-user-ru] Re: [gentoo-user-ru] Re: [gentoo-user-ru] Насущный вопрос о тормозах при интенсивном I/O

[John Brezerk]

[-- Attachment #1: Type: text/plain, Size: 442 bytes --]

2010/3/29 Охрименко Александр <a.a.okhrimenko@gmail.com>

> C отключенными  CONFIG_TASK_IO_ACCOUNTING и CONFIG_TASK_DELAY_ACCT перестал
> работать iotop...
>
> --
> Охрименко А.А.
>

А что вас удивляет?

-- 
Regards,
Malakhov Alexey
q4wine (  http://q4wine.brezblock.org.ua/  ) main developer.
BrezBlock ( http://brezblock.org.ua ) maintainer
e-mail: brezerk@gmail.com
web: http://brezblock.org.ua
BrezBlock, Kiev, Ukraine

[-- Attachment #2: Type: text/html, Size: 939 bytes --]

[gentoo-user-ru] Re: [gentoo-user-ru] Re: [gentoo-user-ru] Re: [gentoo-user-ru] Re: [gentoo-user-ru] Насущный вопрос о тормозах при интенсивном I/O

[Anton Ananich]

Чисто интересно: в портах есть ядро 2.6.16 (оно явно раньше 2.6.18).
Может ли кто-либо подтвердить на основе своей пракики что эта версия
не была затронута описанной проблемой?

Спасибо,
Антон Ананич

2010/3/29 John Brezerk <brezerk@gmail.com>:
>
>
> 2010/3/29 Охрименко Александр <a.a.okhrimenko@gmail.com>
>>
>> C отключенными  CONFIG_TASK_IO_ACCOUNTING и CONFIG_TASK_DELAY_ACCT
>> перестал работать iotop...
>>
>> --
>> Охрименко А.А.
>
> А что вас удивляет?
>
> --
> Regards,
> Malakhov Alexey
> q4wine (  http://q4wine.brezblock.org.ua/  ) main developer.
> BrezBlock ( http://brezblock.org.ua ) maintainer
> e-mail: brezerk@gmail.com
> web: http://brezblock.org.ua
> BrezBlock, Kiev, Ukraine
>

Re: [gentoo-user-ru] Re: [gentoo-user-ru] Re: [gentoo-user-ru] Насущный вопрос о тормозах при интенсивном I/O

[Alex Efros]

Hi!

On Mon, Mar 29, 2010 at 11:47:47AM +0300, Охрименко Александр wrote:
> В SuSe ядре патч какой то есть, мне не удалось посмотреть что он исправляет.

Я где-то год назад изучил ситуацию с другими дистрибутивами, в надежде
найти тот, в котором этой проблемы нет, и выковырять из него
соответствующий патчик для ядра. Но все дистрибутивы тормозили одинаково.

Так что если сейчас появился дистрибутив без этого бага, то для начала
надо бы в этом убедиться - попробуйте загрузить Gentoo с ядром от SuSe.
Если тормозов не будет - надо будет порыться в их патчах и/или связаться с
их разработчиками чтобы уточнить детали.

> По умолчанию ставится ядро с PAE:

По логике, PAE здесь абсолютно не при чём.

-- 
			WBR, Alex.

[gentoo-user-ru] Re: [gentoo-user-ru] Re: [gentoo-user-ru] Re: [gentoo-user-ru] Насущный вопрос о тормозах при интенсивном I/O

[Denis V. Rybakov]

Alex Efros wrote:

> Я где-то год назад изучил ситуацию с другими дистрибутивами, в надежде
> найти тот, в котором этой проблемы нет, и выковырять из него
> соответствующий патчик для ядра. Но все дистрибутивы тормозили одинаково.
>   

Не знаю как тогда, а сейчас это видимо не так.
Ковыряюсь тут с openvz, на ubuntu server, наткнулся на интересные нюансы,
которые могут касаться обсуждаемой проблемы. Впрочем по порядку.

Есть машина hp proliant dl360g4, lspci ниже

00:00.0 Host bridge: Intel Corporation E7520 Memory Controller Hub (rev 0c)
00:02.0 PCI bridge: Intel Corporation E7525/E7520/E7320 PCI Express Port 
A (rev 0c)
00:04.0 PCI bridge: Intel Corporation E7525/E7520 PCI Express Port B 
(rev 0c)
00:06.0 PCI bridge: Intel Corporation E7520 PCI Express Port C (rev 0c)
00:1c.0 PCI bridge: Intel Corporation 6300ESB 64-bit PCI-X Bridge (rev 02)
00:1d.0 USB Controller: Intel Corporation 6300ESB USB Universal Host 
Controller (rev 02)
00:1d.1 USB Controller: Intel Corporation 6300ESB USB Universal Host 
Controller (rev 02)
00:1d.4 System peripheral: Intel Corporation 6300ESB Watchdog Timer (rev 02)
00:1d.5 PIC: Intel Corporation 6300ESB I/O Advanced Programmable 
Interrupt Controller (rev 02)
00:1d.7 USB Controller: Intel Corporation 6300ESB USB2 Enhanced Host 
Controller (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 0a)
00:1f.0 ISA bridge: Intel Corporation 6300ESB LPC Interface Controller 
(rev 02)
00:1f.1 IDE interface: Intel Corporation 6300ESB PATA Storage Controller 
(rev 02)
01:03.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27)
01:04.0 System peripheral: Compaq Computer Corporation Integrated Lights 
Out Controller (rev 01)
01:04.2 System peripheral: Compaq Computer Corporation Integrated Lights 
Out  Processor (rev 01)
02:01.0 RAID bus controller: Compaq Computer Corporation Smart Array 
64xx (rev 01)
02:02.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5704 
Gigabit Ethernet (rev 10)
02:02.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5704 
Gigabit Ethernet (rev 10)
06:00.0 PCI bridge: Intel Corporation 6700PXH PCI Express-to-PCI Bridge 
A (rev 09)
06:00.2 PCI bridge: Intel Corporation 6700PXH PCI Express-to-PCI Bridge 
B (rev 09)


стоит на ней ubuntu-server-9.10-x86_64

родное ядро там
# dpkg -l | grep linux-server
ii  linux-server                      2.6.31.20.33                      
Complete Linux kernel on Server Equipment.

все работало, шустро, описанных проблем с производительностью не 
наблюдалось.
недавече мне приспичило воткнуть туда openvz. родных openvz ядер там нет.
попалась на глаза тема, что перцы из openvz решили приурочить к выпуску 
10.04-lts и rhel6 докучи
свое новое ядрышко http://community.livejournal.com/openvz/30934.html
решился обкатать, набор патчей там идет поверх ваниллы, брал здесь
http://download.openvz.org/kernel/branches/2.6.32/2.6.32-afanasyev.1/patches/patch-afanasyev.1-combined.gz

что из этого получилось после сборки

# dpkg -l | grep openvz
ii  linux-image-2.6.32.10-openvz      2.6.32.10-openvz-10.00.Custom     
Linux kernel binary image for version 2.6.32

и вот с этим ядром вдруг откуда ни возьмись вылезли эти самые тормоза.

проверялось банально, записью большого файла на файловую систему (ext4)
dd if=/dev/zero of=/raw-test.bin bs=1M count=10000
на родном ядре имею порядка 80Мб/с
на самосборном - порядка 30Мб/с

да, надо заметить, что конфиг там идентичный. если детально, то был взят 
конфиг от
2.6.31.20.33, подложен в 2.6.32.10-openvz, прогнан через oldconfig, в 
котором я ответил буквально на 2-3 вопроса,
касательно модулей для железа, после чего через menuconfig была включена 
функциональность openvz.

для неоспоримости выводов было бы неплохо проверить, будет ли тормозить 
ванильное 2.6.32.10 без openvz патчей,
но что-то мне подсказывает, что будет. проверю по возможности.

а если так, то в наборе убунтовских патчей, есть что-то, что решает 
данную проблему.
и дело тут не в конфигурации, io-шедулерах или чем-то еще.

надеюсь чем-то был полезен.


Удачи.

Re: [gentoo-user-ru] Re: [gentoo-user-ru] Насущный вопрос о тормозах при интенсивном I/O

[Sergey Kobzar]

On 03/29/10 09:04, Охрименко Александр wrote:
> Если когда нибудь эта проблема будет устранена, напишите пожалуйста
> сюда, в рассылку. На данный момент не вижу возможности использования
> Gentoo в продакшене, оставаясь с актуальным ядром. Перехожу на S.u.S.e.,
> там ничего не тормозит и обновления регулярные...

А в Suse какое ядро? Они используют какие-то патчи для него близкие к теме?