NiTr0 Опубликовано 31 декабря, 2014 · Жалоба Думаю да. Особенно если учесть что у последнего еще и латентность памяти ниже (первый - с северным мостом на отдельном кристалле на общей подложке, немногим быстрее кор2). Гипертрединг можно попробовать и отключить - не уверен что с него профит будет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Wingman Опубликовано 1 января, 2015 · Жалоба Стоит, если сетевушки многопоточные, и получится нормально раскидать прерывания по ядрам Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
purecopper Опубликовано 2 марта, 2015 · Жалоба Коллеги, а никто не в курсе, что за зверь такой - hpet_next_event.isra.6? perf top: 7,51% [kernel] [k] hpet_next_event.isra.6 6,76% [kernel] [k] do_raw_spin_lock 5,42% [cls_u32] [k] u32_classify 5,39% [igb] [k] igb_poll Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 2 марта, 2015 · Жалоба HPET используется как clock source Смотреть почему не юзается tsc. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
purecopper Опубликовано 2 марта, 2015 · Жалоба Так в том-то и дело - cat /sys/devices/system/clocksource/clocksource0/current_clocksource tsc Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 2 марта, 2015 · Жалоба А в dmesg ничегостранного нет? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SyJet Опубликовано 3 марта, 2015 · Жалоба Так в том-то и дело - cat /sys/devices/system/clocksource/clocksource0/current_clocksource tsc А случаем не UEFI режим? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
evgen.v Опубликовано 3 марта, 2015 · Жалоба Добрый день! Помогите, пожалуйста, с раскидыванием прерываний по ядрам. Есть 3 сетевые карты 82576 и одна 82574L, всего 8 портов, и процессор Xeon 5500. Драйверы сетевух стоят последние с офсайта. Каким образом лучше всего распределить прерывания? Сам я с этим еще не сталкивался Содержимое /proc/interrupts: cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 0: 49943 0 0 0 IO-APIC-edge timer 1: 12 0 0 0 IO-APIC-edge i8042 8: 1 0 0 0 IO-APIC-edge rtc0 9: 0 0 0 0 IO-APIC-fasteoi acpi 12: 155 0 0 0 IO-APIC-edge i8042 16: 0 0 0 0 IO-APIC-fasteoi uhci_hcd:usb3 18: 0 0 0 0 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb8, i801_smbus 19: 0 0 0 0 IO-APIC-fasteoi uhci_hcd:usb5, uhci_hcd:usb7 21: 0 0 0 0 IO-APIC-fasteoi uhci_hcd:usb4 23: 0 0 0 0 IO-APIC-fasteoi ehci_hcd:usb2, uhci_hcd:usb6 42: 6623 0 1228 0 PCI-MSI-edge ahci 43: 358 0 0 0 PCI-MSI-edge ioat-msix 44: 358 0 0 0 PCI-MSI-edge ioat-msix 45: 358 0 0 0 PCI-MSI-edge ioat-msix 46: 358 0 0 0 PCI-MSI-edge ioat-msix 47: 358 0 0 0 PCI-MSI-edge ioat-msix 48: 358 0 0 0 PCI-MSI-edge ioat-msix 49: 358 0 0 0 PCI-MSI-edge ioat-msix 50: 358 0 0 0 PCI-MSI-edge ioat-msix 51: 14 0 0 2108 PCI-MSI-edge enp6s0-rx-0 52: 748 0 0 0 PCI-MSI-edge enp6s0-tx-0 53: 2 0 0 0 PCI-MSI-edge enp6s0 54: 5 0 368 0 PCI-MSI-edge enp7s0-rx-0 55: 0 0 0 0 PCI-MSI-edge enp7s0-tx-0 56: 1 0 0 0 PCI-MSI-edge enp7s0 57: 0 0 0 0 PCI-MSI-edge enp1s0f0 58: 80 293 0 0 PCI-MSI-edge enp1s0f0-TxRx-0 59: 0 0 0 0 PCI-MSI-edge enp1s0f1 60: 5 0 368 0 PCI-MSI-edge enp1s0f1-TxRx-0 61: 0 0 0 0 PCI-MSI-edge enp2s0f0 62: 79 0 0 294 PCI-MSI-edge enp2s0f0-TxRx-0 63: 0 0 0 0 PCI-MSI-edge enp2s0f1 64: 4 0 369 0 PCI-MSI-edge enp2s0f1-TxRx-0 65: 0 0 0 0 PCI-MSI-edge enp3s0f0 66: 79 0 294 0 PCI-MSI-edge enp3s0f0-TxRx-0 67: 0 0 0 0 PCI-MSI-edge enp3s0f1 68: 4 0 369 0 PCI-MSI-edge enp3s0f1-TxRx-0 NMI: 11 4 3 4 Non-maskable interrupts LOC: 8674 14917 10812 26232 Local timer interrupts SPU: 0 0 0 0 Spurious interrupts PMI: 11 4 3 4 Performance monitoring interrupts IWI: 235 366 533 448 IRQ work interrupts RTR: 3 0 0 0 APIC ICR read retries RES: 1519 1534 1203 1104 Rescheduling interrupts CAL: 642 751 563 636 Function call interrupts TLB: 31 37 47 19 TLB shootdowns TRM: 0 0 0 0 Thermal event interrupts THR: 0 0 0 0 Threshold APIC interrupts MCE: 0 0 0 0 Machine check exceptions MCP: 4 4 4 4 Machine check polls ERR: 0 MIS: 0 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
purecopper Опубликовано 3 марта, 2015 · Жалоба NiTr0 В dmesg есть [ 0.000000] hpet clockevent registered [ 0.561556] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 40, 41, 42, 43, 44, 0 [ 0.561562] hpet0: 8 comparators, 64-bit 14.318180 MHz counter [ 0.563729] hpet: hpet2 irq 40 for MSI [ 0.563803] hpet: hpet3 irq 41 for MSI [ 0.563878] hpet: hpet4 irq 42 for MSI [ 0.567828] hpet: hpet5 irq 43 for MSI [ 0.567855] Switching to clocksource hpet [ 2.084128] Refined TSC clocksource calibration: 2399.971 MHz. [ 2.084131] Switching to clocksource tsc [ 2.084362] rtc0: alarms up to one month, y3k, 114 bytes nvram, hpet irqs На irq 40-43 40: 2298045419 0 0 0 HPET_MSI-edge hpet2 41: 0 2219695714 0 0 HPET_MSI-edge hpet3 42: 0 0 2212596893 0 HPET_MSI-edge hpet4 43: 0 0 0 2342376678 HPET_MSI-edge hpet5 SyJet Нет, UEFI нет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 3 марта, 2015 (изменено) · Жалоба Добрый день! Помогите, пожалуйста, с раскидыванием прерываний по ядрам. Есть 3 сетевые карты 82576 и одна 82574L, всего 8 портов, и процессор Xeon 5500. Драйверы сетевух стоят последние с офсайта. Каким образом лучше всего распределить прерывания? Сам я с этим еще не сталкивался Содержимое /proc/interrupts: cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 0: 49943 0 0 0 IO-APIC-edge timer 1: 12 0 0 0 IO-APIC-edge i8042 8: 1 0 0 0 IO-APIC-edge rtc0 9: 0 0 0 0 IO-APIC-fasteoi acpi 12: 155 0 0 0 IO-APIC-edge i8042 16: 0 0 0 0 IO-APIC-fasteoi uhci_hcd:usb3 18: 0 0 0 0 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb8, i801_smbus 19: 0 0 0 0 IO-APIC-fasteoi uhci_hcd:usb5, uhci_hcd:usb7 21: 0 0 0 0 IO-APIC-fasteoi uhci_hcd:usb4 23: 0 0 0 0 IO-APIC-fasteoi ehci_hcd:usb2, uhci_hcd:usb6 42: 6623 0 1228 0 PCI-MSI-edge ahci 43: 358 0 0 0 PCI-MSI-edge ioat-msix 44: 358 0 0 0 PCI-MSI-edge ioat-msix 45: 358 0 0 0 PCI-MSI-edge ioat-msix 46: 358 0 0 0 PCI-MSI-edge ioat-msix 47: 358 0 0 0 PCI-MSI-edge ioat-msix 48: 358 0 0 0 PCI-MSI-edge ioat-msix 49: 358 0 0 0 PCI-MSI-edge ioat-msix 50: 358 0 0 0 PCI-MSI-edge ioat-msix 51: 14 0 0 2108 PCI-MSI-edge enp6s0-rx-0 52: 748 0 0 0 PCI-MSI-edge enp6s0-tx-0 53: 2 0 0 0 PCI-MSI-edge enp6s0 54: 5 0 368 0 PCI-MSI-edge enp7s0-rx-0 55: 0 0 0 0 PCI-MSI-edge enp7s0-tx-0 56: 1 0 0 0 PCI-MSI-edge enp7s0 57: 0 0 0 0 PCI-MSI-edge enp1s0f0 58: 80 293 0 0 PCI-MSI-edge enp1s0f0-TxRx-0 59: 0 0 0 0 PCI-MSI-edge enp1s0f1 60: 5 0 368 0 PCI-MSI-edge enp1s0f1-TxRx-0 61: 0 0 0 0 PCI-MSI-edge enp2s0f0 62: 79 0 0 294 PCI-MSI-edge enp2s0f0-TxRx-0 63: 0 0 0 0 PCI-MSI-edge enp2s0f1 64: 4 0 369 0 PCI-MSI-edge enp2s0f1-TxRx-0 65: 0 0 0 0 PCI-MSI-edge enp3s0f0 66: 79 0 294 0 PCI-MSI-edge enp3s0f0-TxRx-0 67: 0 0 0 0 PCI-MSI-edge enp3s0f1 68: 4 0 369 0 PCI-MSI-edge enp3s0f1-TxRx-0 NMI: 11 4 3 4 Non-maskable interrupts LOC: 8674 14917 10812 26232 Local timer interrupts SPU: 0 0 0 0 Spurious interrupts PMI: 11 4 3 4 Performance monitoring interrupts IWI: 235 366 533 448 IRQ work interrupts RTR: 3 0 0 0 APIC ICR read retries RES: 1519 1534 1203 1104 Rescheduling interrupts CAL: 642 751 563 636 Function call interrupts TLB: 31 37 47 19 TLB shootdowns TRM: 0 0 0 0 Thermal event interrupts THR: 0 0 0 0 Threshold APIC interrupts MCE: 0 0 0 0 Machine check exceptions MCP: 4 4 4 4 Machine check polls ERR: 0 MIS: 0 Не совсем понятно зачем вы сделали такую конфигурацию. Ведь 82576 каждая имеет по 8 очередей. То есть у вас 8х3 + 82574L ( вроде бы 2 очереди ) = 25 векторов потенциально. И всего 4 процессора. Процессоры реальные или с HT? Распределять просто: той карте у которой больше всего нагрузка, давать больше всего процессоров. Начинайте с 1 вектора на каждую карту и повесьте их каждый на отдельный процессор. А потом по нагрузке: совмещайте какие-то вектора на одном процессоре, и добавляйте новые вектора на загруженной карте. Но вообще это изврат. Убежден, что все решила бы одна карта 82576 с ВЛАНами. Изменено 3 марта, 2015 пользователем Dark_Angel Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Antares Опубликовано 5 марта, 2015 · Жалоба Заметил закономерность, с которой пока не понятно как бороться. Имеем Linux на базе SLES, ядро 3.11.6, на серваке крутится NAT, DNS и BGP. Примерно раз в 170 дней происходит падение. Трафика в это время не так много. Где то давненько находил тему про падение раз в пол года серваков на линуксе, но найти не могу. Ни кто не сталкивался с этим? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pppoetest Опубликовано 6 марта, 2015 · Жалоба То же где то читал, там вроде что-то переполнялось. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Antares Опубликовано 6 марта, 2015 · Жалоба То же где то читал, там вроде что-то переполнялось. Вот бы знать что. А то на ровно месте хлоп и всё, хорошо не в ЧНН Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
aabc Опубликовано 13 марта, 2015 (изменено) · Жалоба Antares Начните с того, чтоб залогить текст OOPS. Изменено 13 марта, 2015 пользователем aabc Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Antares Опубликовано 13 марта, 2015 · Жалоба И ждать ещё пол года, когда упадёт. Не вариант Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
worky Опубликовано 28 марта, 2015 (изменено) · Жалоба Есть пару вопросов: 1) Сколько может выжать килопакетов под акцелем с ПППоЕ на X10SLM-F c Intel® Xeon® CPU E3-1230 v3 @ 3.30GHz? Хотелось бы иметь ориентир. И стоит ли ли активирвать HT? 2) Какой нынче дистр для НАСа больше всего юзают? Изменено 28 марта, 2015 пользователем worky Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
uzd Опубликовано 2 апреля, 2015 · Жалоба Добрый день. Прошу помочь с траблшутингом появления ksoftirqd на NAT под Linux. В качестве дистрибутива использую Gentoo с ядром 3.18.10. Пытаюсь собрать конфигурацию, которая сможет стабильно маршрутизировать и НАТить 15-17 гиг трафика. Для начала тестировал на сервере с 20 ядрами (2 x Xeon E5-2660 v2 @ 2.20GHz) и сетевой Intel с двумя портами 10GbE 82599ES, которые собраны в LACP Bond. Но у этого сервера был потолок по CPU на 12-13 гигах. После этого взял сервер с 32 ядрами (2 x Xeon E5-2698 v3 @ 2.30GHz) и с той же сетевой начал тестировать. На 8-9 гигабитах трафика все было великолепно - нагрузка на все CPU по 20-30%. Но на отметке в 11 гигабит резко повылазили ksoftirqd, которые полностью ложат сервер по 100% нагрузке на CPU. Пытался найти причину проблемы по perf top. При 8-9 гигабитах трафика: PerfTop: 105978 irqs/sec kernel:99.8% exact: 0.0% [4000Hz cycles], (all, 32 CPUs) -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 5.22% [kernel] [k] hash_net4_test 5.19% [kernel] [k] _raw_spin_lock 4.98% [ixgbe] [k] ixgbe_clean_rx_irq 4.65% [kernel] [k] ip_set_test 4.35% [kernel] [k] acpi_safe_halt 3.96% [ixgbe] [k] ixgbe_poll 3.94% [kernel] [k] irq_entries_start 3.52% [kernel] [k] _raw_spin_lock_bh 3.25% [kernel] [k] fib_table_lookup 2.96% [kernel] [k] delay_tsc 2.66% [kernel] [k] ipt_do_table 2.53% [kernel] [k] __nf_conntrack_find_get 2.40% [kernel] [k] __dev_queue_xmit 2.29% [ixgbe] [k] ixgbe_xmit_frame_ring 2.27% [kernel] [k] _raw_read_lock_bh 1.94% [kernel] [k] _raw_read_unlock_bh 1.50% [kernel] [k] __slab_free 1.43% [kernel] [k] cpu_startup_entry 1.29% [kernel] [k] get_nohz_timer_target 1.28% [kernel] [k] __local_bh_enable_ip 1.23% [kernel] [k] ip_route_input_noref 1.21% [kernel] [k] check_leaf.isra.10 1.20% [kernel] [k] hash_net4_kadt 1.16% [kernel] [k] nf_iterate 1.11% [kernel] [k] ip_finish_output 1.06% [kernel] [k] skb_release_head_state 0.95% [ixgbe] [k] ixgbe_read_reg 0.94% [kernel] [k] put_page 0.72% [kernel] [k] consume_skb 0.67% [kernel] [k] __netif_receive_skb_core 0.60% [kernel] [k] menu_select 0.56% [kernel] [k] tcp_packet 0.56% [kernel] [k] set_match_v3 0.54% [kernel] [k] nf_conntrack_tuple_taken 0.51% [kernel] [k] int_sqrt А в момент, когда сервер ложит из-за ksoftirqd: PerfTop: 42849 irqs/sec kernel:99.3% exact: 0.0% [4000Hz cycles], (all, 32 CPUs) ------------------------------------------------------------------------------------------------------------------------------------------------------------ 22.99% [kernel] [k] _raw_read_unlock_bh 17.86% [kernel] [k] ip_set_test 17.53% [kernel] [k] _raw_read_lock_bh 12.49% [kernel] [k] hash_net4_kadt 2.67% [kernel] [k] hash_net4_test 2.26% [kernel] [k] _raw_spin_lock 1.83% [ixgbe] [k] ixgbe_clean_rx_irq 1.48% [kernel] [k] delay_tsc 1.31% [kernel] [k] fib_table_lookup 1.27% [kernel] [k] __nf_conntrack_find_get 1.27% [kernel] [k] __dev_queue_xmit 1.09% [ixgbe] [k] ixgbe_xmit_frame_ring 1.04% [kernel] [k] ipt_do_table 0.60% [kernel] [k] __slab_free 0.56% [kernel] [k] check_leaf.isra.10 0.55% [kernel] [k] ip_route_input_noref 0.54% [kernel] [k] ip_finish_output Графики из cacti приаттачил. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Abram Опубликовано 2 апреля, 2015 · Жалоба uzd, Смотрите. На втором месте - ip_set_test, т.е. поиск по ipset. Там есть такой кусок: read_lock_bh(&set->lock); ret = set->variant->kadt(set, skb, par, IPSET_TEST, opt); read_unlock_bh(&set->lock); Вот ваши lock и unlock - на первом и на третьем месте. Попробуйте для проверки исключить ipset из iptables. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
uzd Опубликовано 2 апреля, 2015 · Жалоба uzd, Смотрите. На втором месте - ip_set_test, т.е. поиск по ipset. Там есть такой кусок: read_lock_bh(&set->lock); ret = set->variant->kadt(set, skb, par, IPSET_TEST, opt); read_unlock_bh(&set->lock); Вот ваши lock и unlock - на первом и на третьем месте. Попробуйте для проверки исключить ipset из iptables. Действительно, помогло. 65% нагрузки при 19 гигах трафика. Спасибо. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 2 апреля, 2015 · Жалоба Теоретически его возможно nftables заменить Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SABRE Опубликовано 4 апреля, 2015 · Жалоба А поменять тип списка не поможет? Теоретически его возможно nftables заменить А они не слишком сырые? И будет ли выигрыш? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 4 апреля, 2015 · Жалоба Как говорят - архитектура лучше. Будет ли - это еще тот вопрос, у меня максимум 4 гига бегает, и простора даже для теста ipset маловато - nftables не могу протестить толком и сравнить (смысла нет, пока не уперлось в проц, как у вас). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
worky Опубликовано 8 мая, 2015 (изменено) · Жалоба Кстати да, по поводу энергосбережения: всякие C1E и прочие speedstep желательно отключать. Это же касается хостов с виртуализацией. Можно тут подробнее узнать по этой теме: ссылка Изменено 8 мая, 2015 пользователем worky Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dyr Опубликовано 9 ноября, 2015 (изменено) · Жалоба Пара вопросов. 1. Можно ли выгружать статистику одновременно и в netflow v5(на один источник) и в ipFix (на другой источник)? 2. Вижу увеличенную загрузку cpu0, это можно как-то поправить? root@nata3:/root/src/ipt-netflow# cat /proc/net/stat/ipt_netflow ipt_NETFLOW 2.1-14-g22ddee7-dirty, srcversion C42613919255BC3C4EDE719; aggr llist nel Protocol version 5 (netflow) Timeouts: active 1800s, inactive 15s. Maxflows 4194304 Natevents enabled, count start 19146948, stop 18539301. Flows: active 64448 (peak 74164 reached 0d0h8m ago), mem 75606K, worker delay 1/250 [1..25] (0 ms, 0 us, 275:0 0 [cpu1]). Hash: size 8388608 (mem 65536K), metric 1.00 [1.00, 1.00, 1.00]. InHash: 82604325 pkt, 69167611 K, InPDU 0, 0. Rate: 1397558614 bits/sec, 204166 packets/sec; Avg 1 min: 1419817358 bps, 207512 pps; 5 min: 1405045571 bps, 205283 pps cpu# pps; <search found new [metric], trunc frag alloc maxflows>, traffic: <pkt, bytes>, drop: <pkt, bytes> Total 204165; 11633630 2047451690 33901238 [1.00], 0 0 0 0, traffic: 2081352928, 1727975 MB, drop: 0, 0 K cpu0 129458; 5014029 925984132 15868106 [1.00], 0 0 0 0, traffic: 941852238, 780848 MB, drop: 0, 0 K cpu1 25360; 1904874 343753506 5648888 [1.00], 0 0 0 0, traffic: 349402394, 285243 MB, drop: 0, 0 K cpu2 21467; 2137686 376609670 6004310 [1.00], 0 0 0 0, traffic: 382613980, 324934 MB, drop: 0, 0 K cpu3 27880; 2577041 401104382 6379934 [1.00], 0 0 0 0, traffic: 407484316, 336948 MB, drop: 0, 0 K Export: Rate 674904 bytes/s; Total 4799774 pkts, 6701 MB, 71996610 flows; Errors 0 pkts; Traffic lost 0 pkts, 0 Kbytes, 0 flows. sock0: 192.168.254.88:9996, sndbuf 1048576, filled 1, peak 48386; err: sndbuf reached 0, connect 0, cberr 0, other 0 sock1: 217.119.16.114:9996, sndbuf 1048576, filled 1, peak 115201; err: sndbuf reached 0, connect 0, cberr 0, other 0 aggr#0 port: ports 1024-65535 replace 1024 (usage 2945629980) Изменено 9 ноября, 2015 пользователем Dyr Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
aabc Опубликовано 9 ноября, 2015 · Жалоба Dyr 1. Нельзя. 2. Так у вас приходит трафик на процы. Вы можете управлять этим через RSS и RPS. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...