ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Unix-системы [игнор отключен] [закрыт для гостей] / Apache долго отвечает на запросы
8 сообщений из 8, страница 1 из 1
Apache долго отвечает на запросы
    #37720547
Cresh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Cresh
Гость
Ранее публиковал вопрос, но ответа так и не получил.
CreshСервер настроен для работы в локальной сети и прекрасно работал до некоторого времени,
после которого он стал выборочно долго отвечать, т/е есть компы с которых все открывается моментально,
а есть на оборот - причем закономерности в выборе этих компов не наблюдается,
причем список тех у кого быстро открывается постоянен - это машим 5-6, а остальные 100 тупят по страшному.

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

Сетевые настройки поже тоже верные, потому что даже на админские машины попали в список неугодных.

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


Сейчас в руках оказался сниффер и вот что обнаружилось:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
No.     Time        Source                Destination           Protocol Info
   
4090 \t81.423934   10.90.253.95          192.168.200.211       TCP      56667 > http [SYN] Seq=0 Win=8192 Len=0 MSS=1380 WS=2
\x0c   
4091 \t81.423976   192.168.200.211       10.90.253.95          TCP      http > 56667 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 WS=6
\x0c   
4093 \t81.632276   10.90.253.95          192.168.200.211       TCP      56667 > http [ACK] Seq=1 Ack=1 Win=66240 Len=0
\x0c   
4094 \t81.659198   10.90.253.95          192.168.200.211       HTTP     GET /?index HTTP/1.1 
\x0c   
4095 \t81.659243   192.168.200.211       10.90.253.95          TCP      http > 56667 [ACK] Seq=1 Ack=364 Win=6912 Len=0
\x0c   
4096 \t81.661704   192.168.200.211       10.90.253.95          TCP      53121 > etlservicemgr [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=439338 TSER=0 WS=6
\x0c   
4307 \t84.659834   192.168.200.211       10.90.253.95          TCP      53121 > etlservicemgr [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=440088 TSER=0 WS=6
\x0c   
4592 \t90.659835   192.168.200.211       10.90.253.95          TCP      53121 > etlservicemgr [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=441588 TSER=0 WS=6
\x0c   
5649 \t102.714806  192.168.200.211       10.90.253.95          TCP      [TCP segment of a reassembled PDU]
\x0c   
5650 \t102.714847  192.168.200.211       10.90.253.95          TCP      [TCP segment of a reassembled PDU]
\x0c   
5651 \t102.715092  192.168.200.211       10.90.253.95          TCP      [TCP segment of a reassembled PDU]
\x0c   
5661 \t102.723553  10.90.253.95          192.168.200.211       TCP      56667 > http [ACK] Seq=364 Ack=2102 Win=66240 Len=0
\x0c   
5662 \t102.723570  192.168.200.211       10.90.253.95          HTTP     HTTP/1.1 200 OK  (text/html)
\x0c   
5683 \t102.927840  192.168.200.211       10.90.253.95          TCP      [TCP Retransmission] [TCP segment of a reassembled PDU]
\x0c   
5694 \t102.934863  10.90.253.95          192.168.200.211       TCP      56667 > http [ACK] Seq=364 Ack=2107 Win=66232 Len=0 SLE=2102 SRE=2107
\x0c   
7028 \t117.732658  192.168.200.211       10.90.253.95          TCP      http > 56667 [FIN, ACK] Seq=2107 Ack=364 Win=6912 Len=0
\x0c   
7031 \t117.882658  10.90.253.95          192.168.200.211       TCP      56667 > http [ACK] Seq=364 Ack=2108 Win=66232 Len=0
\x0c   
7032 \t117.882823  10.90.253.95          192.168.200.211       TCP      56667 > http [RST, ACK] Seq=364 Ack=2108 Win=0 Len=0

Мое внимание привлекли фреймы 4096, 4307 и 4592 тем что такие фреймы есть только при обращении с "тупящей машины",
при обращении с нормально работающей машины такой фрейм один, плюс именно на них и происходит задержка по времени.

Коллеги по цеху гугл молчит - посоветуйте куда глядеть.
...
Рейтинг: 0 / 0
23.03.2012, 17:46
| Ответить | Цитировать | Написать  
Apache долго отвечает на запросы
    #37720562
Cresh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Cresh
Гость
Совсем забыл добавить Апач крутится на сервере:
Код: plaintext
Debian Linux 2.6.32-5-686
...
Рейтинг: 0 / 0
23.03.2012, 17:58
| Ответить | Цитировать | Написать  
Apache долго отвечает на запросы
    #37720573
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
У нас разный гугль? http://whatportis.com/9001

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

netstat -p в момент обращения покажет какой именно процесс пытается установить контакт.
Его и надо мучить.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
23.03.2012, 18:03
| Ответить | Цитировать | Написать  
Apache долго отвечает на запросы
    #37720653
Cresh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Cresh
Гость
Dimitry SibiryakovУ нас разный гугль? http://whatportis.com/9001


Конечно нет, но я имел ввиду гугл не помогает понять чем собственно занимается эта служба.

Dimitry SibiryakovНа тех машинах, которые не тупят файерволл либо отключен либо этот порт занесён в
разрешённые, поэтому тот, кто к нему обращается, быстро получает отлуп и успокаивается. У
остальных он вынужден ждать таймаут подключения.


Вы абсолютно правы насчет файрвола, спасибо огромное, сам не допер.

Dimitry Sibiryakovnetstat -p в момент обращения покажет какой именно процесс пытается установить контакт.
Его и надо мучить.


Собственно на клиенте показывает только http соединение, а на сервере то же что и сниффер.


Теперь проблема в следующем -
Отключение файрвола полностью решает проблему,
теперь включаем обратно и делаем правила для порта 9001
для протоколов TCP и UDP но ничего хорошего из этого не выходит.
...
Рейтинг: 0 / 0
23.03.2012, 19:02
| Ответить | Цитировать | Написать  
Apache долго отвечает на запросы
    #37720664
Cresh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Cresh
Гость
Собственно встал еще один вопрос - что исправить на сервере что-бы не нужно было мучать файрвол клиентов?
Ведь по сути это обычный веб сайт.
...
Рейтинг: 0 / 0
23.03.2012, 19:07
| Ответить | Цитировать | Написать  
Apache долго отвечает на запросы
    #37720746
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
CreshСобственно на клиенте показывает только http соединение, а на сервере то же что и сниффер.

Вам сниффер показывает PID процесса, пытающегося установить соединение? Так какого ж Вы
мучаете форум вместо этого процесса?..
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
23.03.2012, 20:09
| Ответить | Цитировать | Написать  
Apache долго отвечает на запросы
    #37720750
Мутаген
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мутаген
Гость
Может, кто-то случайно поставил на сервер TOR? Если он там не нужен, то стоит убрать и посмотреть. Если нужен, то настраивать.
...
Рейтинг: 0 / 0
23.03.2012, 20:14
| Ответить | Цитировать | Написать  
Apache долго отвечает на запросы
    #37722658
Cresh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Cresh
Гость
Проблема решилась, это был php xDebug косо настроенный =)
...
Рейтинг: 0 / 0
26.03.2012, 10:29
| Ответить | Цитировать | Написать  
8 сообщений из 8, страница 1 из 1
Форумы / Unix-системы [игнор отключен] [закрыт для гостей] / Apache долго отвечает на запросы
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]