kaN5300 Опубликовано 31 января, 2012 · Жалоба Накатил на парочку насов 9.0-RELEASE. Обновлялся через cvsup в обоих случаях с 7.4-STABLE до RELENG_9_0. После ребута пересборка и обновление всех портов (включая переход с mpd 5.5 на mpd-5.6) удаление устаревших либов и еще один ребут. Весь процесс обновления проходил удаленно. Первый тазик блестяще выстоял вечер воскресенья, после чего я принял решение по обновлению второго (о чем потом правда пожалел). Сетап обоих тазов такой: Ядро стандартное + ipfw_nat и нетграф Лоадер: net.graph.maxdata=65536 net.graph.maxalloc=65536 net.graph.maxdgram="128000" net.graph.recvspace="128000" kern.hz="1000" hw.igb.rxd=4096 hw.igb.txd=4096 hw.igb.max_interrupt_rate=32000 hw.igb.enable_aim=0 сисктл: dev.igb.0.rx_processing_limit=-1 dev.igb.1.rx_processing_limit=-1 dev.igb.0.enable_aim=0 dev.igb.1.enable_aim=0 net.inet.ip.forwarding=1 net.inet.ip.fastforwarding=1 net.inet.ip.redirect=0 net.inet.ip.intr_queue_maxlen=10240 net.inet.tcp.delayed_ack=0 net.inet.tcp.sendspace=3217968 net.inet.tcp.recvspace=3217968 net.inet.tcp.blackhole=2 net.inet.tcp.drop_synfin=1 net.inet.udp.recvspace=65535 net.inet.udp.maxdgram=57344 net.inet.udp.blackhole=1 net.inet.icmp.drop_redirect=1 net.inet.icmp.icmplim=100 kern.ipc.nmbclusters=400000 kern.ipc.somaxconn=8192 kern.ipc.maxsockbuf=83886080 kern.ipc.maxsockets=204800 net.local.stream.recvspace=65535 net.local.stream.sendspace=65535 net.link.ether.inet.proxyall=1 net.link.ifqmaxlen=10240 net.graph.maxdgram=8388608 net.graph.recvspace=8388608 net.inet.tcp.tso=0 Обращаю внимание на то что net.isr принудительно через sysctl нигде не указан и на тазах с 7.4 картина такая: <kan5300@nas6>sysctl -a | grep isr net.isr.swi_count: 1616339 net.isr.drop: 0 net.isr.queued: 1763717 net.isr.deferred: 0 net.isr.directed: -1514625606 net.isr.count: -1583659636 net.isr.direct: 1 net.route.netisr_maxqlen: 4096 <kan5300@nas6>uptime 10:48AM up 42 days, 3:46, 1 user, load averages: 1.19, 1.28, 1.37 На 9.0 картина такая: net.isr.numthreads: 1 net.isr.maxprot: 16 net.isr.defaultqlimit: 256 net.isr.maxqlimit: 10240 net.isr.bindthreads: 0 net.isr.maxthreads: 1 net.isr.direct: 0 net.isr.direct_force: 0 net.isr.dispatch: direct net.route.netisr_maxqlen: 256 Пиковые нагрузки на все тазы представляют в пиках до 800 pptp-туннелей, прокачка при этом около 40 kpps и пиковый lavg доходит до 5. Количество паник на 7.4 в среднем по 30 дней аптайма на сервак. Второй тазик с 9.0 пока себя показывает нормально, а вот первый произвольно уходит в ребут при kpps около 30 и выше при этом не оставляя никаких дампов для анализа. После ребута в /var/crash ничего нет за исключением старинного vmcore от прошлого года. За отсутствием дампа можно только гадать, изза чего это происходит. И я грежу на выставленный в ноль net.isr. На опеннете пишут что в 9.0 net.isr.direct только для чтения и предлагают использовать net.isr.direct_dispatch профили (direct, hybrid, deferred). Вот вырезка из комментариев к исходнику: SYSCTL_NODE(_net, OID_AUTO, isr, CTLFLAG_RW, 0, "netisr"); /*- * Three global direct dispatch policies are supported: * * NETISR_DISPATCH_QUEUED: All work is deferred for a netisr, regardless of * context (may be overriden by protocols). * * NETISR_DISPATCH_HYBRID: If the executing context allows direct dispatch, * and we're running on the CPU the work would be performed on, then direct * dispatch it if it wouldn't violate ordering constraints on the workstream. * * NETISR_DISPATCH_DIRECT: If the executing context allows direct dispatch, * always direct dispatch. (The default.) * * Notice that changing the global policy could lead to short periods of * misordered processing, but this is considered acceptable as compared to * the complexity of enforcing ordering during policy changes. Protocols can * override the global policy (when they're not doing that, they select * NETISR_DISPATCH_DEFAULT). */ Не совсем понятно, стоит ли включать в моем случае net.isr, т.к. драйвер igb в нашей ситуации прекрасно справляется с привязкой очередей к процессам. И в результате в top всегда утилизация всех CPU распределена равномерно (как на 7.4 так и на 9.0). Вопрос лишь в том, как добиться стабильной работы. dadv в своей статье "Тюнинг FreeBSD 8.2. Часть 1. Стабильность. (ЖЖ)" описывает проблему "dangling pointer", которая особенно проявляется при слишком частом или резком одновременном удалении системных интерфейсов под высокой нагрузкой. Но эта проблема вроде как должна быть уже решена на момент выхода 9.0 RELEASE за счет стараний Глеба Смирнова, который внес исправления в 9-CURRENT в 2011 году, насколько я понял из статьи. Врубать или не врубать ISR? И вторая мысль, опираясь на статью dadv. Пора переходить на amd64 архитектуру, ибо есть мнение что это не приведет к переполнению различных структур данных на прокаченных системах. По этому мы будем планировать постепенный ввод amd64 дистрибутивов и попробуем поиграться с режимами работы net.isr. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Hawk128 Опубликовано 31 января, 2012 · Жалоба Перевел НАСы на 9.0. Работают стабильно. Паник нет и не было вообще. Нагрузка до 1600 сессий в основном pptp + pppoe. Трафик через сервак по 500-600 kpps всего на вход и выход (около 150-200 на вход и столько же на выход каждой из сетевых). Так что пилите, и все будет хорошо. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kaN5300 Опубликовано 31 января, 2012 · Жалоба У нас боксы с решением all-in-one с nat/shaper/firewall/netflow. Что-то мне подсказывает, что у вас часть этих функций выполняет вышестоящая железяка. Так? Укажите пожалуйста используемую архитектуру и "sysctl -a | grep net.isr". Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Zohan Опубликовано 31 января, 2012 · Жалоба kaN5300, однозначно переходить на amd64. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kaN5300 Опубликовано 31 января, 2012 · Жалоба Завтра будем инсталлить amd64/fbsd9.0 на ящик на базе i7 990X (про выбор сервера обсуждали здесь). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
roysbike Опубликовано 31 января, 2012 · Жалоба Поставил 9.0 , после установки обновлял сорсы через svn . mdp5.6 + PF_NAT . HP proliant hw.model: Intel® Xeon® CPU E31240 @ 3.30GHz. Сетевухи igb0 igb1. Нагрузка смешная, не успел прокачать под нагрузкой/ На днях поставлю на второй, выложу результаты vpnxxx# uname -a FreeBSD vpn123.xxxxx 9.0-STABLE FreeBSD 9.0-STABLE #3 r230372: Fri Jan 20 07:46:43 UTC 2012 root@vpnxxxx:/usr/obj/usr/src/sys/GENERIC.current1 i386 vpnxxxx# netstat -w1 -h input (Total) output packets errs idrops bytes packets errs bytes colls 55k 0 0 35M 60k 0 47M 0 59k 0 0 39M 63k 0 52M 0 55k 0 0 33M 59k 0 46M 0 58k 0 0 36M 64k 0 50M 0 61k 0 0 38M 67k 0 52M 0 58k 0 0 38M 63k 0 51M 0 56k 0 0 35M 64k 0 52M 0 62k 0 0 40M 70k 0 58M 0 vpnxxxx# sysctl -a | grep isr net.isr.numthreads: 1 net.isr.maxprot: 16 net.isr.defaultqlimit: 256 net.isr.maxqlimit: 10240 net.isr.bindthreads: 0 net.isr.maxthreads: 1 net.isr.direct: 0 net.isr.direct_force: 0 net.isr.dispatch: direct net.route.netisr_maxqlen: 4096 last pid: 78236; load averages: 0.63, 0.66, 0.62 up 5+16:10:55 22:48:13 114 processes: 6 running, 75 sleeping, 33 waiting CPU 0: 0.8% user, 0.0% nice, 7.8% system, 7.5% interrupt, 83.9% idle CPU 1: 0.4% user, 0.0% nice, 5.9% system, 8.6% interrupt, 85.1% idle CPU 2: 1.2% user, 0.0% nice, 4.3% system, 7.5% interrupt, 87.1% idle CPU 3: 0.8% user, 0.0% nice, 3.5% system, 3.9% interrupt, 91.8% idle Mem: 19M Active, 329M Inact, 325M Wired, 212K Cache, 112M Buf, 3115M Free Swap: 4096M Total, 4096M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 155 ki31 0K 32K CPU2 2 122.9H 95.26% idle{idle: cpu2} 11 root 155 ki31 0K 32K RUN 3 125.0H 92.19% idle{idle: cpu3} 11 root 155 ki31 0K 32K RUN 1 119.5H 89.70% idle{idle: cpu1} 11 root 155 ki31 0K 32K RUN 0 115.3H 81.59% idle{idle: cpu0} 12 root -92 - 0K 272K WAIT 2 325:31 6.05% intr{irq263: igb1:que} 13 root -16 - 0K 32K sleep 2 380:46 5.37% ng_queue{ng_queue2} 13 root -16 - 0K 32K sleep 3 381:31 4.88% ng_queue{ng_queue3} 13 root -16 - 0K 32K sleep 0 381:18 4.88% ng_queue{ng_queue0} 13 root -16 - 0K 32K sleep 3 380:51 4.69% ng_queue{ng_queue1} 12 root -92 - 0K 272K WAIT 0 318:42 4.39% intr{irq256: igb0:que} 12 root -92 - 0K 272K WAIT 0 332:59 4.30% intr{irq261: igb1:que} 12 root -92 - 0K 272K WAIT 1 330:21 4.30% intr{irq262: igb1:que} 12 root -92 - 0K 272K CPU3 3 323:35 4.20% intr{irq264: igb1:que} 12 root -92 - 0K 272K WAIT 1 105:45 1.56% intr{irq257: igb0:que} 12 root -92 - 0K 272K WAIT 2 102:19 1.37% intr{irq258: igb0:que} 12 root -92 - 0K 272K WAIT 3 107:03 1.27% intr{irq259: igb0:que} 1004 root 20 0 15064K 6728K select 0 63:39 0.20% snmpd 0 root -92 0 0K 168K - 1 40:17 0.10% kernel{igb0 que} 995 root 20 0 110M 46036K select 0 80:34 0.00% mpd5{mpd5} 12 root -60 - 0K 272K WAIT 0 17:49 0.00% intr{swi4: clock} 15 root -16 - 0K 8K - 1 11:35 0.00% yarrow 2 root -16 - 0K 8K pftm 0 8:09 0.00% pfpurge 0 root -92 0 0K 168K - 0 7:56 0.00% kernel{igb1 que} 8 root 16 - 0K 8K syncer 0 3:14 0.00% syncer 0 root -92 0 0K 168K - 1 2:05 0.00% kernel{igb1 que} 0 root -92 0 0K 168K - 2 2:00 0.00% kernel{igb1 que} 0 root -16 0 0K 168K sched 1 1:53 0.00% kernel{swapper} 0 root -92 0 0K 168K - 0 1:34 0.00% kernel{igb1 que} 877 root 20 0 9612K 1376K select 2 1:17 0.00% syslogd 1015 nagios 20 0 9568K 1348K select 2 0:11 0.00% nrpe2 12 root -60 - 0K 272K WAIT 1 0:10 0.00% intr{swi4: clock} Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kaN5300 Опубликовано 31 января, 2012 · Жалоба roysbike, спасибо за выкладку результатов. Вижу, что isr вы также как и мы принудительно не выставляли. Сегодня наш второй таз на девятке поставил новый рекорд. 92 kpps / 700 tuns 1 minute lavg в пиковый момент протяженностью около 20 минут подпрыгнул до 6.8. Вечером колебался между 3.0 - 4.0. Самое главное - обошлось без ребутов, чего мы больше всего опасались. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kaN5300 Опубликовано 2 февраля, 2012 · Жалоба Кто-нибудь пытался запустить utm5_frw на 9.0 amd64? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 2 февраля, 2012 · Жалоба Врубать или не врубать ISR? Пока прерывания сетевых карт равномерно нагружают все процессорные ядра - лучше не надо. Пора переходить на amd64 архитектуру На шлюзе разницы не видно. Ни по производительности, ни по надёжности. У нас боксы с решением all-in-one с nat/shaper/firewall/netflow. Аналогично, но nat через pf. Аптайм до 930 суток. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
adeep Опубликовано 2 февраля, 2012 · Жалоба Кто-нибудь пытался запустить utm5_frw на 9.0 amd64? работает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kaN5300 Опубликовано 2 февраля, 2012 · Жалоба Кто-нибудь пытался запустить utm5_frw на 9.0 amd64? работает. У нас тоже пошло всё ровно. compat7x-amd64-7.3.703000.201008_1 поставили и всё завелось. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Giga-Byte Опубликовано 5 февраля, 2012 · Жалоба был неприятный момент когда все коннекты отвалились (PPPoE и PPTP на одной машине), mpd выпал с воплями на No buffer space available на какойто операции с нодами. по SSH к серверу достучался, но весь софт хором кричал No Buffer Space Available, в т.ч. и mpd, даже ICMP не ходил. Увеличения памяти, MAXUSERS, пересборка ядра с нужными опциями - никчему не приводило, всё отваливалось через несколько часов снова. Анализ штатными утилитами используемой памяти криминала не выявил. Уменьшил kern.maxsockbuf до 256к, пока работает, может уже недельку. 9.0-RELEASE amd64 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kirush Опубликовано 6 февраля, 2012 · Жалоба крутите netgraph: net.graph.maxdgram=8388608 net.graph.recvspace=8388608 kern.ipc.maxsockbuf=83886080 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dyr Опубликовано 6 февраля, 2012 · Жалоба И лучше гуглите. Например Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tunny Опубликовано 6 февраля, 2012 · Жалоба был неприятный момент когда все коннекты отвалились (PPPoE и PPTP на одной машине), mpd выпал с воплями на No buffer space available на какойто операции с нодами. по SSH к серверу достучался, но весь софт хором кричал No Buffer Space Available, в т.ч. и mpd, даже ICMP не ходил. Увеличения памяти, MAXUSERS, пересборка ядра с нужными опциями - никчему не приводило, всё отваливалось через несколько часов снова. Анализ штатными утилитами используемой памяти криминала не выявил. Уменьшил kern.maxsockbuf до 256к, пока работает, может уже недельку. 9.0-RELEASE amd64 дайте памяти нетграфу Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 6 февраля, 2012 · Жалоба No Buffer Space Available, в т.ч. и mpd, даже ICMP не ходил - не хватка сетевых буферов (мбуф), vmstat -z, смотреть столбик Fail, не смотреть "ХХ Bucket". и netstat -m kern.ipc.nmbclusters=262144 # Maximum number of mbuf clusters allowed // netstat -m kern.ipc.nmbjumbop=262144 # Maximum number of mbuf page size jumbo clusters allowed. pagesize(4k/8k) kern.ipc.nmbjumbo9=262144 # Maximum number of mbuf 9k jumbo clusters allowed kern.ipc.nmbjumbo16=262144 # Maximum number of mbuf 16k jumbo clusters allowed Не стоит боятся их задирать, по факту это задаёт максимально возможное количество элементов, а не фактически их выделяет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Giga-Byte Опубликовано 7 февраля, 2012 · Жалоба :) написал же, не выявил криминала. возможно это даже не фряшная проблема, поставил вторую машину, попробую выявить. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 8 февраля, 2012 · Жалоба крутите netgraph: net.graph.maxdgram=8388608 net.graph.recvspace=8388608 kern.ipc.maxsockbuf=83886080 А откуда такие "страшные" цифры? Для интереса попробовал "на летУ" установить net.graph.maxdgram=8388608 и net.graph.recvspace=8388608. mpd тут же ушёл в ступор (ошибка 678 у виндовых клиентов).. Пришлось вернуть всё взад и ребутать mpd. Правда перед этим не увеличивал kern.ipc.maxsockbuf (262144) и дело было на 8.0 P.S. Нагуглил довольно интересную подборку статей (kirush, не ваша случаем ? ;-)), изучаю.. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Giga-Byte Опубликовано 9 февраля, 2012 · Жалоба AlKov, вот после таких утверждений меня работа и находит :)))) жаль смайликов подходящих нету, выразить Ымоции пы.сы. надо прекращать флейм, обсуждаем ТЕМУ Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kaN5300 Опубликовано 9 февраля, 2012 · Жалоба крутите netgraph: net.graph.maxdgram=8388608 net.graph.recvspace=8388608 kern.ipc.maxsockbuf=83886080 А откуда такие "страшные" цифры? Для интереса попробовал "на летУ" установить net.graph.maxdgram=8388608 и net.graph.recvspace=8388608. mpd тут же ушёл в ступор (ошибка 678 у виндовых клиентов).. Пришлось вернуть всё взад и ребутать mpd. Правда перед этим не увеличивал kern.ipc.maxsockbuf (262144) и дело было на 8.0 P.S. Нагуглил довольно интересную подборку статей (kirush, не ваша случаем ? ;-)), изучаю.. У Дадва офигенные статьи. Отправил их в мемориз и засветился в коментах. Спрашивал, будут ли заметки о 9.0. Сказал что в продакш дот-зироу релизы не выставляет. Так что ждем 9.1 и тыкаем dadv'a. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kaN5300 Опубликовано 9 февраля, 2012 (изменено) · Жалоба Тот инсталл который помирал был отброшен на 7.4-RELEASE и вобще там не все в порядке с железом, это отдельный вопрос. Тот второй сервер о котором я писал всё-таки допустил один произвольный ребут. Самое интересное происходит на нашем новом NAS на базе процессора i7-990X. Туда был накачен 9.0-RELEASE amd64 с последующим обновлением до 9.0-STABLE. Сервак проработал пока чуть больше суток. В пике 35 kpps, 700 туннелей и idle самого загруженного ядра составлял при этом 70%. Видно что запас по производительности есть. Теперь главное - добиться стабильной работы. Изменено 9 февраля, 2012 пользователем kaN5300 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
roysbike Опубликовано 10 февраля, 2012 · Жалоба Тот инсталл который помирал был отброшен на 7.4-RELEASE и вобще там не все в порядке с железом, это отдельный вопрос. Тот второй сервер о котором я писал всё-таки допустил один произвольный ребут. Самое интересное происходит на нашем новом NAS на базе процессора i7-990X. Туда был накачен 9.0-RELEASE amd64 с последующим обновлением до 9.0-STABLE. Сервак проработал пока чуть больше суток. В пике 35 kpps, 700 туннелей и idle самого загруженного ядра составлял при этом 70%. Видно что запас по производительности есть. Теперь главное - добиться стабильной работы. зачем вы используете amd64? На каком чипе используете сетевые карты? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 11 февраля, 2012 · Жалоба И всё же - можно где-то узнать "происхождение" этих параметров? net.graph.maxdgram=8388608 net.graph.recvspace=8388608 kern.ipc.maxsockbuf=83886080 Почему именно 8 388 608 (8 Мб??) и 83 886 080 (80 Мб??) И есть ли какое-то соотношение между значением net.graph.maxdgram и kern.ipc.maxsockbuf? Связаны ли эти параметры с размером памяти? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Giga-Byte Опубликовано 12 февраля, 2012 · Жалоба И всё же - можно где-то узнать "происхождение" этих параметров? net.graph.maxdgram=8388608 net.graph.recvspace=8388608 kern.ipc.maxsockbuf=83886080 Почему именно 8 388 608 (8 Мб??) и 83 886 080 (80 Мб??) И есть ли какое-то соотношение между значением net.graph.maxdgram и kern.ipc.maxsockbuf? Связаны ли эти параметры с размером памяти? из /dev/random ^))) kirush, объясни же человеку Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dadv Опубликовано 5 марта, 2012 · Жалоба И всё же - можно где-то узнать "происхождение" этих параметров? net.graph.maxdgram=8388608 net.graph.recvspace=8388608 kern.ipc.maxsockbuf=83886080 Почему именно 8 388 608 (8 Мб??) и 83 886 080 (80 Мб??) И есть ли какое-то соотношение между значением net.graph.maxdgram и kern.ipc.maxsockbuf? Связаны ли эти параметры с размером памяти? Это параметры из моей статьи. Они прекрасно работают у меня на 4G памяти и amd64 (использовать i386 для таких задач - нарываться на неприятности, даже если памяти меньше 4G). kern.ipc.maxsockbuf влияет, в частности, на работу команды ngctl list, которой очень удобно снимать количество подключенных сессий (она отрабатывает на порядок быстрее чем ifconfig). Но ngctl list при большом количестве сессий вместо результата выдавало у меня ошибку даже после нескольких удвоений дефолта, вплоть до 8M. Тогда, обозлившись, я удесятерил - и ngctl list заработал. Это было при более чем 1500 сессях. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...