Ru-Board.club
← Вернуться в раздел «В помощь системному администратору»

» SQUID (только под *nix)

Автор: niko7
Дата сообщения: 21.04.2009 08:41
Подскажите, можно ли реализовать учет трафика каждого пользователя, получение отчета
по каждому и по всем пользователям. Отключение пользователя в случае превышения
пользователем выделенного ему лимита?
Автор: BONDBIG
Дата сообщения: 21.04.2009 08:43
niko7
SAMS - неплохая система.
Автор: MadMas
Дата сообщения: 21.04.2009 09:41

Цитата:
Ну еще бы. Ведь надо вот так:

Код:
no_cache deny all

а не

Код:
cache deny all


блин, ни так ни эдак не работает один сплошной ACCESS DENIED.
Я просто менял файл конфига и делал squid - k reconfigure, может надо было перестартовать сквид полностью ?

P.S. Юзеры начинают нервничать после таких экспериментов
Автор: Ruza
Дата сообщения: 22.04.2009 19:33
MadMas
Добавь ещё и icp_access alow all
Автор: MadMas
Дата сообщения: 23.04.2009 08:27

Цитата:
Добавь ещё и icp_access alow all


Добавил перед no_cache deny all , те же пироги
Автор: ohlos
Дата сообщения: 23.04.2009 10:45
Squid 2.6.14
Жил-поживал себе кэш cache_dir diskd /work/cache/squid 9000 16 256

Но вняв совету, что кэш есть плохо, решил избавиться от него и заменил на cache_dir null /temp
И при перезагрузке сервера перестал стартовать squid - Starting WWW-proxy squid (/var/cache/squid) - failed while creating cache_dir

Хотя вручную потом запускается. Думал может нужно указать адрес кэша, но замена на cache_dir null /work/cache/squid и выполнение squid -z ситуации не изменило.

Куда плясать?
Автор: ipmanyak
Дата сообщения: 23.04.2009 13:32
ohlos
Can I make Squid proxy only, without caching anything?
Чтобы юзать null с cahe_dir в 2.6 нужно компилять сквид с опцией --enable-storeio=null,...

Автор: ohlos
Дата сообщения: 23.04.2009 21:14
ipmanyak
Считаешь ./configure --enable-storeio=ufs,null будет достаточно?
Или может вместо этого можно обойтись этим:
acl all src 0.0.0.0/0.0.0.0
cache deny all
Автор: tankistua
Дата сообщения: 23.04.2009 21:40
какое отношение имеют вкомпиленные опции к acl-ям ?
Автор: MadMas
Дата сообщения: 24.04.2009 10:57
Заметил один прикол, периодически сообщение:

The following error was encountered:

* Read Error

The system returned:

(104) Connection reset by peer

An error condition occurred while reading data from the network. Please retry your request.

Your cache administrator is root.

идет не от моего сервака, а от провайдерского, может быть это у него траблы со скоростью или еще с чем, а не у меня и из-за его глюков и у меня начинаются проблемы? И еще один вопрос, кто такие соседи ? Может быть мне нужно настроить провайдерский прокси как соседа ?
Автор: ohlos
Дата сообщения: 24.04.2009 22:54
tankistua

Цитата:
какое отношение имеют вкомпиленные опции к acl-ям ?


Вообще-то вроде я вопросы задавал, а не отвечал на них.
Но отвечу - без acl сквид обругается на all всякими нехорошими буржуйскими словами
Автор: tankistua
Дата сообщения: 24.04.2009 23:37
а - ну тогда конечно понятно.

шел дождь и рота красноармейцев - это примерно тоже самое.

З.Ы. собери последнюю версию - не занимайся глупостями
Автор: ohlos
Дата сообщения: 25.04.2009 00:44
tankistua
Глупости - это давать подобные советы.
Проблема вполне решаема была и на более ранних версиях. Просто стремно на рабочем серваке эксперементировать, вот и думал умных речей здесь послушать, укрепиться в намерениях, но видно не судьба
Автор: tankistua
Дата сообщения: 25.04.2009 01:01
ну какие умные вещи - берите да пробуйте.

Экспериментировать на рабочем серваке как минимум глупо - у меня для тестов 2-ух процессорный Р3-866/512/40Гб, бюджет подозреваю баксов 80, на текущий момент, небольше.
Автор: DShtorm
Дата сообщения: 26.04.2009 10:15
Так в чем проблема ????
MadMas

Инсталируй еще один Сквид любой современной версии ( у меня последний 2,7 )
Дай ему другой порт ( в отличии от первого )
И играйся с ним пока первый обслуживает сетку

Когда решишь , что работает нормально , убивай первый , меняй порт на втором
и вперед !!!

Добавлено:
Кстати раз я уже добрался до форума

Хотел вопросик задать , в общем проблема у меня такая
что кеш ( на мой взгляд ) както не так кешит
, вот смотрю я к примеру
полсетки обновляет DrWeb , а записи в логе TCP_MISS ( по grep drweb )

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

В общем такая ситуация как с картинкой и со многими популярными программами , которые я точно знаю должны быть в кеше ( сетка человек на 300 , постоянно качают mail агенты ,
аськи и тд )

+ вопрос №2 ( легкий )
Какой процент экономии трафика на Вашем Сквиде ???


У меня стоит 2,7 из последних
в LightSquid дает средний процент - 14,33

Автор: Ruza
Дата сообщения: 26.04.2009 18:53
MadMas
Поговори с провом...

Цитата:
И еще один вопрос, кто такие соседи ?

cache_peer
icp_port

tankistua

Цитата:
шел дождь и рота красноармейцев - это примерно тоже самое.

Но от тайги, до британских морей...

ohlos

Цитата:
Считаешь ./configure --enable-storeio=ufs,null будет достаточно?
Или может вместо этого можно обойтись этим:
acl all src 0.0.0.0/0.0.0.0
cache deny all

Ну это кто как хочет так и...
Только тебе решать что лучше
http://www.squid-cache.org/Doc/config/cache/


Цитата:
Проблема вполне решаема была и на более ранних версиях. Просто стремно на рабочем серваке эксперементировать, вот и думал умных речей здесь послушать, укрепиться в намерениях, но видно не судьба

Не тут только сам... В первом случае кеш вообще создан не будет а во втором просто запрет кеширования.

DShtorm

Цитата:
вот смотрю я к примеру
полсетки обновляет DrWeb , а записи в логе TCP_MISS ( по grep drweb )

Сквид скорее всего выполняет инструкции nocache
request_header_access Cache-Control - должно помочь

Цитата:
Еще пример есть у меня картинка полметровая в нете лежит , гружу ее первый раз ,
гружу второй ( берет из кеша ) , гружу к примеру на следующий день , уже тащит из нета
( ориентируюсь по логам )

refresh_pattern в помощь...


Цитата:
+ вопрос №2 ( легкий )
Какой процент экономии трафика на Вашем Сквиде ???

Это чисто субъективно...
у меня на 4-х от 2 до 18
Автор: BONDBIG
Дата сообщения: 26.04.2009 19:23
DShtorm
Вам реально необходимо кеширование? Ведь кроме выгоды, обычно незначительной, кеширование несет кучу заморочек. И многие админы (и я из их числа), взвесив все "за" и "против" отказались от кеширования насовсем, интернет сильно изменился, это раньше он в массе своей составлял набор полустатических сайтов, сейчас контент меняется "на лету" и кеширование на уровне приложений уже привносит больше проблем, чем выгоды. Более того, сегодня самым узким местом в компьютерах является дисковая подсистема, зачем ее насиловать лишний раз тучей мелких файлов? Еще куда ни шло, когда кеш в одном большом файле, но и от него не намного легче.
Другое дело - кеширование на сетевом уровне, но к проксированию это уже имеет мало отношения...
Автор: Ruza
Дата сообщения: 26.04.2009 20:24
BONDBIG

Цитата:
Более того, сегодня самым узким местом в компьютерах является дисковая подсистема

Это вы о чём?
Автор: BONDBIG
Дата сообщения: 26.04.2009 21:00

Цитата:
Это вы о чём?

Эмм.. О накопителях на жестких магнитных дисках. Эта "запчасть" в современных компьютерах наиболее анахронична, все остальные элементы развиваются гораздо быстрее. Возьмите хотя бы скорость чтения/записи - жалкие десятки мегабайт в секунду. Например при работе в гигабитных сетях, обычные САТАшки уже являются самым медленным местом, приходится строить рейды и покупать сказёвые диски. Я уже молчу об операциях перемещения головки (брр!). Кроме вентиляторов, харды - единственный механический элемент в сегодняшних компьютерах.
Вы не согласны?
Автор: ohlos
Дата сообщения: 27.04.2009 00:31
Ruza

Цитата:

Цитата: Считаешь ./configure --enable-storeio=ufs,null будет достаточно?
Или может вместо этого можно обойтись этим:
acl all src 0.0.0.0/0.0.0.0
cache deny all


Ну это кто как хочет так и...
Только тебе решать что лучше
Автор: BONDBIG
Дата сообщения: 27.04.2009 06:04
ohlos
Ничего сложного в переконфигурации программ нет. Качаешь исходник нужной версии, распаковываешь, далее читаешь файл INSTALL внутри. Обычно необходимо сделать
./configure [какиие-то опции], если есть какие-то зависимые пакеты, тебе об этом скажут, затем
make и
make install.
./configure --help тебе выдаст список возможных опций.

Добавлено:

Цитата:
Я ттоже думаю, что через acl далеко не лучшее решение.

Через указанный acl запрещается ЛЮБОЕ кеширование, а через cache_dir null /null отключается лишь дисковый кеш, но остается кеш в оперативке.
Автор: tankistua
Дата сообщения: 27.04.2009 07:16
по-поводу кеширования.

14 процентов - это реально круто :)

P.S. ну какой смысл что-то кешировать, когда скорость 2 мегабита допустим. У меня из 8 офисов минимальная скорость 1 мегабит. Основвная масса - 2 мегабита.
Автор: digital422
Дата сообщения: 27.04.2009 09:04
Народ, подскажите, что поменять в выражении для вывода незакомментированных строк конфиг. файла Squid3 вместе со значением "# TAG:"

grep ^[^#]. /etc/squid3/squid.conf
Автор: Ruza
Дата сообщения: 27.04.2009 11:18
BONDBIG

Цитата:
Кроме вентиляторов, харды - единственный механический элемент в сегодняшних компьютерах.

С этим согласен. Просто несколько страниц назад tankistua написал о скоростях накопителей и скоростях внешних каналов...

ohlos

Цитата:
Но и с переконфигурацией сквида дела не имел, почему и хотелось бы уточнить правильность действий и формата команды.

Это действительно не так сложно...
Для полной уверенности выведи squid -v > ./configure.txt посмотри как был сконфигурирован текущий, и собери сквид с теми же параметрами +

Цитата:
--enable-storeio= те что у тебя были null


tankistua

Цитата:
ну какой смысл что-то кешировать, когда скорость 2 мегабита допустим. У меня из 8 офисов минимальная скорость 1 мегабит. Основвная масса - 2 мегабита.

Ну у меня некоторые и по 4 мегабита, и что?
Тут ИМХО дело к hollywar идёт, не?

Ещё раз ИМХО - тянуть каждому юзеру (снова и снова) картинки с одноклассников, вконтакте и серверов погоды это забивание полосы, будь в ней и 10 мегабит... Дешевле отдать картинку из кеша. А на счёт того что скорость мегабит, 2,3,5 это пока не скрость записи на винчестер, вот когда гигабитные каналы будут, тогда возможно и кеш станет анахронизмом.
Автор: BONDBIG
Дата сообщения: 27.04.2009 11:57

Цитата:
Ещё раз ИМХО - тянуть каждому юзеру (снова и снова) картинки с одноклассников, вконтакте и серверов погоды это забивание полосы, будь в ней и 10 мегабит... Дешевле отдать картинку из кеша.

[holywar mode]Да, оно может быть и дешевле, но работает хорошо только в лабораторных условиях. Взять тех же одноклассников - кеширование раньше приводило к тому, что юзеры попадали на странички друг друга, потом админы одноклассников подкрутили вроде этот баг. И таких примеров много - курсы валют, погода - "вчерашние", потому что одмины сервисов криво выставили ttl страницам и т.п. Согласен насчет
Цитата:
скорость мегабит, 2,3,5

но учтите, что при работе сквида с кешем идет не последовательные чтение/запись, а рандомные, что снижает скорость винчестера на порядок, например с 70 мбайт/с до 3-4 в лучшем случае. Именно это я имел в виду, говоря про "монолитный" кеш-файл и его бенефиты. Несложно грубо посчитать: (3мбайт/с - ~1мбайт/с)*8=~16мбит/с. Вот вам и канал, который "задушит" типовую САТАшку. "~1мбайт/с" в примере - это то, что система сама на себя отъела, скажем на запись логов и т.п. И это идеализированный пример, не учитывающий задержки в самом сквиде при поиске файла в кеше, работы самой ФС, утечки памяти и процессорного времени (сталкивался не раз), связанные с интенсивной работой сквида с диском. По всем прикидкам (геморой с сопровождением кеша+нагрузка на железо+пинки от юзеров > чем стоимость канала/трафика. В конце концов вы не из своего кармана платите, экономьте в первую очередь свои ресурсы, а не "дядины", лучше заняться чем-нибудь более полезным, аудитом/анализом собственной сетевой архитектуры и безопасности сети, например. Выйти с рациональными предложениями к начальству, реализовать проект, получить премию. А ваша возня с кешированием никому, кроме вас не нужна, сами видите - 14% - это мега результат, обычно не более 10%+периодические жалобы на устаревшие страницы=3.5% эффективность вашего кеша. Еще раз повторю - характер информации в интернете сильно изменился с тех пор, когда начинали разрабатывать кеш-прокси сквид. Дело уже порой не в каналах/скоростях записи, а в быстром устаревании информации. Да, если у вас трафик юзеров поддается строгой типизации (типа 100 юзеров открывают 10 раз на дню некий ограниченный список сайтов с большим количеством статики), тогда можно достичь хорошей эффективности кеша. А если счет юзеров идет на тысячи и сайты самые разнообразные, то от кеша только беды.
PS: all above is just my humble opinion.
PPS: Из моего личного опыта - два прокси в кластере генерировали в сумме 8 мбит/с трафика при включенном кеше, после отключения кеша - 12-14 мбит, при том же количестве юзеров. Забавно на графиках это выглядело - такие неслабые прыжки трафика и проходящих реквестов сразу после отключения. Очевидно, что кеш был узким местом, хотя отлажен был так, что ложных кеширований почти не было. попробуйте у себя для эксперимента, если ваши проксюки нагружены прилично, то разница будет очевидна. Если же не будет разницы, то значит вам действительно не нужно отключать кеш. Тест простой, но наглядный, конечно, если приличный мониторинг ведётся, то будет видно.
[/holywar mode]
Автор: tankistua
Дата сообщения: 27.04.2009 16:00

Цитата:
Дешевле отдать картинку из кеша

а вот на этот счет я могу поспорить. У меня есть сервера уровня Р3-800 и такими же винчестерами. Пока не отключил кеширование сквид частенько валился в корку. Т.е. чтобы нормально писать кеш нужен новый сервер. Учитывая скорость в 2 мегабита сервер надо брать нормальный, и винты надо брать нормальные. Разговор минимум на 1К зелени. А сам интернет на текущий момент обходится в 70 баксов.


Вы смотрите на шаг - я на 2. Вы видите в этом выгоду - я вижу в этом проигрыш.
Автор: DShtorm
Дата сообщения: 27.04.2009 23:02
Экономия

Февраль - 16.56% (572.1 G)
Март - 17.82% (797.1 G)
Апрель - 14.12% (592.9 G ) в апреле я его отключал пару раз

Лично я кеш пока оставлю , если до нашего села , доберется
нет хотя бы киевского масштаба , тогда снесу

В принципе работает нормально , крутиться себе на выделенном винте 100 гиговый кеш
и жрет метров 500 памяти ...

PS крутит сетку на 300 пользователей ...
Автор: BONDBIG
Дата сообщения: 28.04.2009 06:17
DShtorm
Что ж, поздравляю, реально хорошие показатели. Видимо у ваших пользователей действительно общие интересы и список посещаемых сайтов. Ну либо такой процент набежал из-за пары больших файлов, скачанных несколькими пользователями, виндовые обновления там, или фильмы/дистры. Мои юзеры фильмы/дистры не качают (запрещено), обновления через MS SMS ставятся и сфера интересов сильно разнится (сквид обслуживает сетку из ~7k юзеров). Из своего опыта в предыдущей конторе (как раз ~300 юзеров) кеш тоже использовался на уровне 10-15%, пока не запретили музыку/фильмы/дистры и не подняли WSUS. Сразу же утилизация кеша упала до 3-4% и он был безжалостно выключен.
Автор: DShtorm
Дата сообщения: 28.04.2009 09:24
У меня стоит максимальный размер файла - 30 метров

десятка top сайтов за год

1 www.mail.ru 7.8 M 113.2 G 5.2% - 7.8 миллионов соеденений :0
2 www.rapidshare.com 44 749 47.7 G 2.2%
3 vkontakte.ru 5.6 M 30.2 G 1.4%
4 mp3.nashe.ru 1 302 19.8 G 0.9%
5 dl.redtube.com 2 800 17.2 G 0.8%
6 213.186.217.210 2.9 M 16.0 G 0.7%
7 au.download.windowsupdate.com 552 330 14.7 G 0.6%
8 stream05.rambler.ru 3 496 12.1 G 0.5%
9 dl.zaycev.net 14 833 11.4 G 0.5%
10 dl4.shareua.com 3 672 10.9 G 0.5%

Там где буква G - это гигабайт
Автор: Ruza
Дата сообщения: 28.04.2009 10:34
Народ - хватит... Я же предупреждал что до флейма дойдём... И останемься только при своих .
Как предложение - написать заметку о +/- кеша в squid и поместить в море шапки. И вопрошающий пусть сам выбирает.

Страницы: 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687

Предыдущая тема: Неполадки в работе DHCP сервера


Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.