ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Java [игнор отключен] [закрыт для гостей] / Долгое закрытие JDBC
59 сообщений из 59, показаны все 3 страниц
  все  
Долгое закрытие JDBC
    #38437182
GorloPavel
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GorloPavel
Участник
Здравствуйте. Проблема такого плана. Существует класс в котором запущен Thread который вызывает эту функцию. Объектов класса может быть несколько сотен, следовательно каждый из них может вызывать эту функцию. Очень часто соединения долго не закрываются. Такое ощущение что хранимая процедура синхронная и пока какой-то поток не выполнит ее, все остальные ждут. Из-за этого некоторые соединения весят по N секунд, хотя сама процедура выполняется по 2-5 миллисекунды. Что не так в коде? Заранее огромное спасибо!

 
Код: java
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.
38.
39.
40.
41.
42.
43.
44.
45.
private void sendHostPreview(int hostId,Packets.ScreenPreview screenPreview){

		Connection mConnection=null;
    	CallableStatement mStatement=null;
		ResultSet mResult=null;
		
		try {
			try {
				screenPreview.host_id=hostId;
				
				mConnection = getDbConnection();
				mConnection.setAutoCommit(false);
				mStatement=mConnection.prepareCall("CALL SEND_HOST_PREVIEW(?)");
				mStatement.setInt(1, hostId);
				mResult=mStatement.executeQuery();
				mConnection.commit();
			
				while(mResult.next()){
					int userId=mResult.getInt(1);
					for (int i=0;i<Hub.SESSIONS.length-1;i++) {
						if(Hub.SESSIONS[i]!=null && Hub.SESSIONS[i].sessionType==Session.SessionType.User && Hub.SESSIONS[i].getUserId()==userId){
							Hub.SESSIONS[i].sendData(screenPreview);
						}
					}
				}
				
			} catch (SQLException e) {
				SessionHelper.logError(e, "sendHostPreview");
			}
		}
		catch(Exception e){
			SessionHelper.logError(e, "sendHostPreview");
		}
		finally{	
			try{
				if(mConnection!=null){}
				if(mStatement!=null){mStatement.close();}
				if(mResult!=null){mResult.close();}
			}
			catch(SQLException e){
				SessionHelper.logError(e, "sendHostPreview");
			}
		}
		
	}

...
Рейтинг: 0 / 0
22.10.2013, 16:13:01
| Ответить | Цитировать | Написать  
Долгое закрытие JDBC
    #38437197
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
GorloPavel,
в субд параллелизм делается за счёт параллельных коннектов. а не потоков в одном коннекте.
Так заточены СУБД.
...
Рейтинг: 0 / 0
22.10.2013, 16:18:32
| Ответить | Цитировать | Написать  
Долгое закрытие JDBC
    #38437270
GorloPavel
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GorloPavel
Участник
Petro123GorloPavel,
в субд параллелизм делается за счёт параллельных коннектов. а не потоков в одном коннекте.
Так заточены СУБД.
Так коннекты то разные получаются. Каждый поток выполняет функцию. И соединение открывается при каждом ее использовании. Получается 10 потоков = 10 соединений. А вот почему долго не падает в finally в некоторых случаях я не пойму.
...
Рейтинг: 0 / 0
22.10.2013, 16:53:44
| Ответить | Цитировать | Написать  
Долгое закрытие JDBC
    #38437283
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
GorloPavelPetro123GorloPavel,
в субд параллелизм делается за счёт параллельных коннектов. а не потоков в одном коннекте.
Так заточены СУБД.
Так коннекты то разные получаются. Каждый поток выполняет функцию. И соединение открывается при каждом ее использовании. Получается 10 потоков = 10 соединений. А вот почему долго не падает в finally в некоторых случаях я не пойму.
проверил? Протестировал?
...
Рейтинг: 0 / 0
22.10.2013, 17:00:20
| Ответить | Цитировать | Написать  
Долгое закрытие JDBC
    #38437314
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Твой код тормозит на mResult=mStatement.executeQuery() ?

Если да - тогда проблема не в Java. Выкладывай текст хранимой процедуры
на неизвестном языке и будем дальше думать куда переносить твой вопрос.
...
Рейтинг: 0 / 0
22.10.2013, 17:18:24
| Ответить | Цитировать | Написать  
Долгое закрытие JDBC
    #38437320
GorloPavel
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GorloPavel
Участник
Petro123GorloPavelпропущено...

Так коннекты то разные получаются. Каждый поток выполняет функцию. И соединение открывается при каждом ее использовании. Получается 10 потоков = 10 соединений. А вот почему долго не падает в finally в некоторых случаях я не пойму.
проверил? Протестировал?

А что тут проверять. Очевидно. У каждого объекта класса есть эта функция. При вызове функции в ее теле создается подключение. И SHOW FULL PROCESSLIST мне показывает несколько подключений. Проблема в том что некоторые подключения живут по 2мс как и положено, а другие по 500 что не является нормальным. В коде тут есть ошибка... Надо: if(mConnection!=null){mConnection.close();}. Но в реальном коде все как положено. Это просто я сейчас эксперементировал и убирал эту строку и незаметил как скопипастил в пост.
...
Рейтинг: 0 / 0
22.10.2013, 17:20:33
| Ответить | Цитировать | Написать  
Долгое закрытие JDBC
    #38437322
GorloPavel
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GorloPavel
Участник
Процедура простая:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
CREATE DEFINER = 'xxx' PROCEDURE `SEND_HOST_PREVIEW`(
        IN host_id INTEGER(11)
    )
    NOT DETERMINISTIC
    CONTAINS SQL
    SQL SECURITY DEFINER
    COMMENT ''
BEGIN
	SELECT uo.user_id FROM users_online uo
	INNER JOIN users_hosts uh on uh.user_id=uo.user_id
	INNER JOIN hosts_online ho on uh.host_id=ho.host_id and ho.host_id=host_id
	GROUP BY uo.user_id;
END;
...
Рейтинг: 0 / 0
22.10.2013, 17:23:17
| Ответить | Цитировать | Написать  
Долгое закрытие JDBC
    #38437367
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
GorloPavelТакое ощущение что хранимая процедура
ну дак и приведи трейс только для хранимки. Без всякой обвязки и цикла по рекордсету.
И коммит тоже лишний, т.к. хранимка только читает.
...
Рейтинг: 0 / 0
22.10.2013, 17:48:36
| Ответить | Цитировать | Написать  
Долгое закрытие JDBC
    #38437386
GorloPavel
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GorloPavel
Участник
Petro123GorloPavelТакое ощущение что хранимая процедура
ну дак и приведи трейс только для хранимки. Без всякой обвязки и цикла по рекордсету.
И коммит тоже лишний, т.к. хранимка только читает.

Про коммит понял. А вот как мне тут от цикла избавиться я не понял :). Кстати тут кокраз массив из тех самых объектов в котором эта функция. В любом случае спасибо вам.
...
Рейтинг: 0 / 0
22.10.2013, 17:56:26
| Ответить | Цитировать | Написать  
Долгое закрытие JDBC
    #38437402
Мужик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мужик
Участник
Petro123И коммит тоже лишний, т.к. хранимка только читает.
Я бы не был так категоричен. Это зависит от уровня изоляции транзакций.
...
Рейтинг: 0 / 0
22.10.2013, 18:01:53
| Ответить | Цитировать | Написать  
Долгое закрытие JDBC
    #38437418
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Не знаю как в этих ваших МайСкл-ях. Но если-бы это был Oracle то нужно оптимизировать
и фазу Execute, и фазу Fetch (в зависимости от удачности выбора плана у нас может
быть одно либо другое). Автор ты добавь себе SessionHelper.trace("Checkpoint1 "+hostId), после входа
в процедуру, потом после execute и потом после завершения считывания строк. В самом конце.
И дай кусок лога. И время в логах сделай с точостью до милисекунд.
...
Рейтинг: 0 / 0
22.10.2013, 18:11:28
| Ответить | Цитировать | Написать  
Долгое закрытие JDBC
    #38437448
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
Мужик,
ну, если рассматривать экзотику и каждую БД, то и Java не нужна.
Изоляция по умолчанию. При обрыве сети ничего без коммита не отвалится...всего один SQL оператор.
Там и хранимку можно убрать imho
...
Рейтинг: 0 / 0
22.10.2013, 18:26:21
| Ответить | Цитировать | Написать  
Долгое закрытие JDBC
    #38437455
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Basil A. Sidorov
Участник
Хранимку нужно убрать.
...
Рейтинг: 0 / 0
22.10.2013, 18:30:49
| Ответить | Цитировать | Написать  
Долгое закрытие JDBC
    #38437515
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Мы не знаем где хранимка ЕЩЕ используется. Убирать нельзя. Но можно
переписать этот код так чтобы от нее не было зависимости в Java.
...
Рейтинг: 0 / 0
22.10.2013, 19:18:31
| Ответить | Цитировать | Написать  
Долгое закрытие JDBC
    #38437795
GorloPavel
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GorloPavel
Участник
maytonМы не знаем где хранимка ЕЩЕ используется. Убирать нельзя. Но можно
переписать этот код так чтобы от нее не было зависимости в Java.
Больше нигде.
...
Рейтинг: 0 / 0
23.10.2013, 04:23:36
| Ответить | Цитировать | Написать  
Долгое закрытие JDBC
    #38437858
maxkar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
maxkar
Участник
GorloPavelЧто не так в коде?

Типичный размер Hub.SESSIONS какой? Какое количество записей в среднем возвращает ваш запрос? У вас на ровном месте сложность цикла O(N*M), где N - размер Hub.SESSIONS, M - размер возвращаемых данных. Вы бы ваш sessions во что-нибудь более приличное преобразовали. В какой-нибудь Map, что-ли. Или не преобразовали, а ввели дополнительный map. Тогда сложность будет либо O(N + M), либо O((M + N) * log(N)), зависит от того, какую map вы возьмете.

Еще. Покажите код вашего SESSIONS[i].sendData. Может, у вас там код тормозит, а не в обращении к хранимке. А открытый курсор (итерации) по результату держат соединения, пока все не обработается.

Ну и на последок. Ваша хранимка оптимально устроена? Вы ее план смотрели? С альтернативами вроде select distinct сравнивали?
...
Рейтинг: 0 / 0
23.10.2013, 09:24:34
| Ответить | Цитировать | Написать  
Долгое закрытие JDBC
    #38437926
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
GorloPavelmaytonМы не знаем где хранимка ЕЩЕ используется. Убирать нельзя. Но можно
переписать этот код так чтобы от нее не было зависимости в Java.
Больше нигде.
Поставь логгирование и дай цифры. Мнеж интересно где в этом Мускле может быть тормоз.
...
Рейтинг: 0 / 0
23.10.2013, 10:13:34
| Ответить | Цитировать | Написать  
Долгое закрытие JDBC
    #38438528
GorloPavel
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GorloPavel
Участник
Функция sendData:
Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
public synchronized Boolean sendData(Object packet) 
   {
		try {
			mClientSocket.getOutputStream().write(mPacketCreator.CreatePacket(Hub.GSON.toJson(packet).getBytes("UTF-8")));
			mClientSocket.getOutputStream().flush();
			return true;
		} catch (Exception e) {
			return false;
		}
	}
...
Рейтинг: 0 / 0
23.10.2013, 15:45:39
| Ответить | Цитировать | Написать  
Долгое закрытие JDBC
    #38438541
GorloPavel
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GorloPavel
Участник
maytonGorloPavelпропущено...

Больше нигде.
Поставь логгирование и дай цифры. Мнеж интересно где в этом Мускле может быть тормоз.

Кусок лога(в скобках System.currentTimeMillis()):
 

Код: java
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.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114.
115.
116.
117.
118.
119.
120.
121.
122.
123.
124.
125.
126.
127.
128.
129.
130.
131.
132.
(1382528493068)sendHostPreview - 37645
(1382528493074)executeQuery - 37645
(1382528493075)finish - 37645
(1382528493081)sendHostPreview - 162197
(1382528493088)executeQuery - 162197
(1382528493090)finish - 162197
(1382528493150)sendHostPreview - 159473
(1382528493238)sendHostPreview - 50559
(1382528493251)executeQuery - 159473
(1382528493253)finish - 159473
(1382528493305)executeQuery - 50559
(1382528493307)finish - 50559
(1382528493447)sendHostPreview - 143614
(1382528493453)executeQuery - 143614
(1382528493454)finish - 143614
(1382528494071)sendHostPreview - 135844
(1382528494078)executeQuery - 135844
(1382528494110)sendHostPreview - 135873
(1382528494115)executeQuery - 135873
(1382528494207)finish - 135844
(1382528494251)finish - 135873
(1382528499536)sendHostPreview - 114161
(1382528499548)executeQuery - 114161
(1382528499576)finish - 114161
(1382528506920)sendHostPreview - 134355
(1382528506925)executeQuery - 134355
(1382528506926)finish - 134355
(1382528509656)sendHostPreview - 48268
(1382528509661)executeQuery - 48268
(1382528509709)finish - 48268
(1382528512849)sendHostPreview - 154548
(1382528512854)executeQuery - 154548
(1382528512854)finish - 154548
(1382528512864)sendHostPreview - 48268
(1382528512869)executeQuery - 48268
(1382528512869)finish - 48268
(1382528512874)sendHostPreview - 114161
(1382528512877)sendHostPreview - 98423
(1382528512879)executeQuery - 114161
(1382528512880)finish - 114161
(1382528512881)executeQuery - 98423
(1382528512881)finish - 98423
(1382528512911)sendHostPreview - 37645
(1382528512915)executeQuery - 37645
(1382528512915)finish - 37645
(1382528512925)sendHostPreview - 159473
(1382528512925)sendHostPreview - 161387
(1382528512928)sendHostPreview - 160985
(1382528512929)executeQuery - 161387
(1382528512929)finish - 161387
(1382528512931)executeQuery - 159473
(1382528512932)finish - 159473
(1382528512932)executeQuery - 160985
(1382528512932)finish - 160985
(1382528512940)sendHostPreview - 139315
(1382528512944)executeQuery - 139315
(1382528512948)finish - 139315
(1382528512949)sendHostPreview - 50559
(1382528512949)sendHostPreview - 139317
(1382528512954)executeQuery - 139317
(1382528512955)finish - 139317
(1382528512956)executeQuery - 50559
(1382528512957)finish - 50559
(1382528513000)sendHostPreview - 162034
(1382528513004)executeQuery - 162034
(1382528513005)finish - 162034
(1382528513057)sendHostPreview - 151492
(1382528513062)executeQuery - 151492
(1382528513062)finish - 151492
(1382528513123)sendHostPreview - 149238
(1382528513127)executeQuery - 149238
(1382528513128)finish - 149238
(1382528513433)sendHostPreview - 131414
(1382528513438)executeQuery - 131414
(1382528513439)finish - 131414
(1382528513523)sendHostPreview - 116886
(1382528513524)sendHostPreview - 162515
(1382528513531)executeQuery - 116886
(1382528513531)finish - 116886
(1382528513532)executeQuery - 162515
(1382528513533)finish - 162515
(1382528513541)sendHostPreview - 161492
(1382528513545)executeQuery - 161492
(1382528513546)finish - 161492
(1382528513553)sendHostPreview - 161497
(1382528513556)executeQuery - 161497
(1382528513561)finish - 161497
(1382528513583)sendHostPreview - 135873
(1382528513587)executeQuery - 135873
(1382528513588)finish - 135873
(1382528513738)sendHostPreview - 135844
(1382528513742)executeQuery - 135844
(1382528513743)finish - 135844
(1382528513763)sendHostPreview - 143614
(1382528513767)executeQuery - 143614
(1382528513767)finish - 143614
(1382528514503)sendHostPreview - 135841
(1382528514509)executeQuery - 135841
(1382528514861)finish - 135841
(1382528517525)sendHostPreview - 161068
(1382528517529)executeQuery - 161068
(1382528517530)finish - 161068
(1382528520258)sendHostPreview - 45635
(1382528520261)executeQuery - 45635
(1382528520266)finish - 45635
(1382528520295)sendHostPreview - 45623
(1382528520299)executeQuery - 45623
(1382528520299)finish - 45623
(1382528527304)sendHostPreview - 121324
(1382528527309)executeQuery - 121324
(1382528527356)sendHostPreview - 122042
(1382528527361)executeQuery - 122042
(1382528527779)finish - 121324
(1382528527785)finish - 122042
(1382528529243)sendHostPreview - 162305
(1382528529247)executeQuery - 162305
(1382528529265)finish - 162305
(1382528532827)sendHostPreview - 136526
(1382528532829)sendHostPreview - 154216
(1382528532829)sendHostPreview - 98423
(1382528532830)sendHostPreview - 96176
(1382528532833)sendHostPreview - 103646
(1382528532840)executeQuery - 154216
(1382528532840)finish - 154216
(1382528532845)executeQuery - 136526
(1382528532845)finish - 136526
(1382528532845)executeQuery - 96176
(1382528532845)finish - 96176
(1382528532846)executeQuery - 98423
(1382528532846)finish - 98423
(1382528532851)executeQuery - 103646
(1382528532858)finish - 103646


...
Рейтинг: 0 / 0
23.10.2013, 15:52:08
| Ответить | Цитировать | Написать  
Долгое закрытие JDBC
    #38438555
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Blazkowicz
Участник
Запустите под профайлером или просто делайте дампы потоков.
Там будет четко видно на чем потоки блокируются.
...
Рейтинг: 0 / 0
23.10.2013, 15:57:25
| Ответить | Цитировать | Написать  
Долгое закрытие JDBC
    #38438559
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
ОК. HostId-s немного смешались. Надо будет рассортировтать их и посчитать интервалы.
...
Рейтинг: 0 / 0
23.10.2013, 15:59:59
| Ответить | Цитировать | Написать  
Долгое закрытие JDBC
    #38438560
GorloPavel
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GorloPavel
Участник
BlazkowiczЗапустите под профайлером или просто делайте дампы потоков.
Там будет четко видно на чем потоки блокируются.

Знать бы еще как это делать. Приложение запущено на удаленной машине. Как снять дамп? Спасибо.
...
Рейтинг: 0 / 0
23.10.2013, 16:00:31
| Ответить | Цитировать | Написать  
Долгое закрытие JDBC
    #38438562
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Blazkowicz
Участник
kill -3 PID
можно jdk/bin/jstack PID
...
Рейтинг: 0 / 0
23.10.2013, 16:03:11
| Ответить | Цитировать | Написать  
Долгое закрытие JDBC
    #38438564
GorloPavel
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GorloPavel
Участник
maytonОК. HostId-s немного смешались. Надо будет рассортировтать их и посчитать интервалы.
Легко вычислить тормозов... Там где сразу подряд finish, значит они не так быстро сработали. Количество SESSIONS = 13k. Количество возвращаемых записей в большинстве случаев не более 2-5.
...
Рейтинг: 0 / 0
23.10.2013, 16:04:30
| Ответить | Цитировать | Написать  
Долгое закрытие JDBC
    #38438565
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Blazkowicz
Участник
А какой размер SESSIONS[]? По одному элементу на поток, или меньше?
...
Рейтинг: 0 / 0
23.10.2013, 16:04:43
| Ответить | Цитировать | Написать  
Долгое закрытие JDBC
    #38438567
GorloPavel
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GorloPavel
Участник
Blazkowiczkill -3 PID
можно jdk/bin/jstack PID
Сейчас 9к потоков. Как потом найти тормоза?
...
Рейтинг: 0 / 0
23.10.2013, 16:06:08
| Ответить | Цитировать | Написать  
Долгое закрытие JDBC
    #38438570
GorloPavel
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GorloPavel
Участник
BlazkowiczА какой размер SESSIONS[]? По одному элементу на поток, или меньше?
13к. Но незанятые null. Что я и проверяю в цикле тоже.
...
Рейтинг: 0 / 0
23.10.2013, 16:06:56
| Ответить | Цитировать | Написать  
Долгое закрытие JDBC
    #38438580
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Blazkowicz
Участник
Нужно отобрать те, которые заблокированы и посмотреть на чем они заблокированы, на JDBC или на synchronized.
...
Рейтинг: 0 / 0
23.10.2013, 16:11:57
| Ответить | Цитировать | Написать  
Долгое закрытие JDBC
    #38438589
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Blazkowicz
Участник
Фига се... 9к потоков. Зачэм стока?
...
Рейтинг: 0 / 0
23.10.2013, 16:13:40
| Ответить | Цитировать | Написать  
Долгое закрытие JDBC
    #38438592
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Blazkowicz
Участник
А можно как-то поймать момент, когда соединение висит N секунд и снять в этот момент дамп потоков?
...
Рейтинг: 0 / 0
23.10.2013, 16:15:34
| Ответить | Цитировать | Написать  
Долгое закрытие JDBC
    #38438601
GorloPavel
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GorloPavel
Участник
BlazkowiczФига се... 9к потоков. Зачэм стока?
Ну сервер в работе :)
...
Рейтинг: 0 / 0
23.10.2013, 16:17:22
| Ответить | Цитировать | Написать  
Долгое закрытие JDBC
    #38438602
GorloPavel
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GorloPavel
Участник
BlazkowiczА можно как-то поймать момент, когда соединение висит N секунд и снять в этот момент дамп потоков?
Сейчас попробую.
...
Рейтинг: 0 / 0
23.10.2013, 16:17:42
| Ответить | Цитировать | Написать  
Долгое закрытие JDBC
    #38438606
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Blazkowicz
Участник
GorloPavelНу сервер в работе :)
Дык по потоку на сессию, это как-то расточительно. Всё равно активных потоков минимум.
...
Рейтинг: 0 / 0
23.10.2013, 16:20:37
| Ответить | Цитировать | Написать  
Долгое закрытие JDBC
    #38438610
GorloPavel
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GorloPavel
Участник
BlazkowiczGorloPavelНу сервер в работе :)
Дык по потоку на сессию, это как-то расточительно. Всё равно активных потоков минимум.
Это сокет соединения. Они должны быть всегда online.
...
Рейтинг: 0 / 0
23.10.2013, 16:21:41
| Ответить | Цитировать | Написать  
Долгое закрытие JDBC
    #38438613
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Blazkowicz
Участник
Можно зашедулить jstack, и запустить тест. Потом отобрать тот дамп, который создан в момент "зависания", согласно логу теста.
Правда, боюсь, с 9К потоков jstack может отнимать слишко много времени :(
...
Рейтинг: 0 / 0
23.10.2013, 16:22:46
| Ответить | Цитировать | Написать  
Долгое закрытие JDBC
    #38438615
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Blazkowicz
Участник
GorloPavelЭто сокет соединения. Они должны быть всегда online.
И что? Из 9K потоков у вас 99% всегда спят. Хорошо что переключение контекста на современном железе уже не такое дорогое. Иначе бы всё умерло. Ну, и линух решает тоже.
...
Рейтинг: 0 / 0
23.10.2013, 16:24:32
| Ответить | Цитировать | Написать  
Долгое закрытие JDBC
    #38438617
Лагман
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Лагман
Участник
а что мешает для начала запустить отдельный инстанс с 1 потоком и посмотреть?
...
Рейтинг: 0 / 0
23.10.2013, 16:25:27
| Ответить | Цитировать | Написать  
Долгое закрытие JDBC
    #38438619
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
GorloPavel,
- сказал же - выруби в коде хождение по датасету и проверь тормоза
- потом ходи по датасету вхолостую
Обычный метод поиска неисправности вырубая блоки поочерёдно.
Логирование - это второй метод поиска.
...
Рейтинг: 0 / 0
23.10.2013, 16:27:13
| Ответить | Цитировать | Написать  
Долгое закрытие JDBC
    #38438631
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Blazkowicz
Участник
Если это game сервер и среди этих 9К сессий много активных, то вполне возможно что sendData этого потока рассылки постоянно конкурирует с остальными 9К потоков за многие synchronized.
Пессимистичные блокировки вообще в многопоточном сервере - зло.
...
Рейтинг: 0 / 0
23.10.2013, 16:35:30
| Ответить | Цитировать | Написать  
Долгое закрытие JDBC
    #38438653
GorloPavel
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GorloPavel
Участник
BlazkowiczЕсли это game сервер и среди этих 9К сессий много активных, то вполне возможно что sendData этого потока рассылки постоянно конкурирует с остальными 9К потоков за многие synchronized.
Пессимистичные блокировки вообще в многопоточном сервере - зло.
Это сервер одного популярного приложения для OS Android. Ну ведь synchronized sendData актуален только для самого потока. Он никак не может конкурировать с остальными. Максимум с одним. Хотя... Hub.GSON.toJson это static поле в классе Hub. И насколько я понял GSON потокобезопасен, следовательно synchronized. Вот тогда он и может конкурировать с остальными 9к, так как в них существует еще несколько функций с использованием GSON. Может в этом проблема?
...
Рейтинг: 0 / 0
23.10.2013, 16:41:57
| Ответить | Цитировать | Написать  
Долгое закрытие JDBC
    #38438663
Лагман
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Лагман
Участник
GorloPavel,

автор потокобезопасен, следовательно synchronized совсем не обязательно. Хотя GSON вообще сам по себе очень медленный, если его использовать без кастомных мапперов.
Проблема ещё может быть в fetchSize = 1 (у постгре по дефолту кажется 1), поставьте его чуть более чем ожидаете получить записей (ну если их не более 2-3, как Вы утверждаете).
Алсо непонятно зачем там комит и автокомит, вы же вроде только читаете данные (хотя тут я не уверен, давно в голом jdbc не копался).
...
Рейтинг: 0 / 0
23.10.2013, 16:47:06
| Ответить | Цитировать | Написать  
Долгое закрытие JDBC
    #38438667
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Blazkowicz
Участник
GorloPavelНу ведь synchronized sendData актуален только для самого потока.
Что значит актуален? У вас в SESSION, вероятно есть и другие synchronized методы, которые гарантируют целостность записи пакетов в сокет. И у вас 9К потоков, которые использую эти методы. С этим проблем нет, и даже перфоманс нормальный, благодаря Biased Locking. Но тут приходится 9К+1й поток и начинает использовать те же самые сокеты, работа с которыми синхронизирована.
В результате в 9К вызов sendData N% приводят к блокировке на synchronized.
Вот такая теория...
Кстати ещё интересно, если вдруг у вас в SESSION есть и запись и чтение, то они используют один и тот же лок. Хотя запись с чтением сокета могут происходить безопасно в разных потоках.

GorloPavel Он никак не может конкурировать с остальными. Максимум с одним.
Почему? Из 9К потоков только один активный?

GorloPavelИ насколько я понял GSON потокобезопасен, следовательно synchronized.
facepalm
...
Рейтинг: 0 / 0
23.10.2013, 16:48:42
| Ответить | Цитировать | Написать  
Долгое закрытие JDBC
    #38438669
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Blazkowicz
Участник
Вообще запуск с сэмплирующим профайлером или просто анализ дампов может показать причину без всяких угадаек.
...
Рейтинг: 0 / 0
23.10.2013, 16:49:57
| Ответить | Цитировать | Написать  
Долгое закрытие JDBC
    #38438670
GorloPavel
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GorloPavel
Участник
автор Хотя GSON вообще сам по себе очень медленный, если его использовать без кастомных мапперов.
Что посоветуете? Сейчас я пользуюсь сериализацией-десереализацией. Воде быстренько все.
...
Рейтинг: 0 / 0
23.10.2013, 16:50:37
| Ответить | Цитировать | Написать  
Долгое закрытие JDBC
    #38438677
Лагман
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Лагман
Участник
GorloPavel,

Для начала бы локализовать текущую проблему ).

GorloPavelВоде быстренько
Ну не знаю как сейчас, я пару лет назад смотрел, массив из 1000 даблов сериализовался около 1 секунды на Core 2 duo 2ГГц. Но там можно прикручиавть свои мапперы, чтоб не использовалась рефлексия и т.п., так что я думаю надо посмотреть что к чему.
...
Рейтинг: 0 / 0
23.10.2013, 16:55:52
| Ответить | Цитировать | Написать  
Долгое закрытие JDBC
    #38438682
GorloPavel
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GorloPavel
Участник
BlazkowiczGorloPavelНу ведь synchronized sendData актуален только для самого потока.
Что значит актуален? У вас в SESSION, вероятно есть и другие synchronized методы, которые гарантируют целостность записи пакетов в сокет. И у вас 9К потоков, которые использую эти методы. С этим проблем нет, и даже перфоманс нормальный, благодаря Biased Locking. Но тут приходится 9К+1й поток и начинает использовать те же самые сокеты, работа с которыми синхронизирована.
В результате в 9К вызов sendData N% приводят к блокировке на synchronized.
Вот такая теория...
Кстати ещё интересно, если вдруг у вас в SESSION есть и запись и чтение, то они используют один и тот же лок. Хотя запись с чтением сокета могут происходить безопасно в разных потоках.

GorloPavel Он никак не может конкурировать с остальными. Максимум с одним.
Почему? Из 9К потоков только один активный?

GorloPavelИ насколько я понял GSON потокобезопасен, следовательно synchronized.
facepalm
Потому что в логике сервера с одним потоком может взаимодействовать только один поток. Включая вызывать его sendData со своими данными. Не понял как sendData одного потока может блокировать sendData во всех потоках?
...
Рейтинг: 0 / 0
23.10.2013, 16:56:28
| Ответить | Цитировать | Написать  
Долгое закрытие JDBC
    #38438685
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Blazkowicz
Участник
Зашедульте jstack на каждую секунду с добавлением в файл. Запустите тест. Отшедульте jstack. В полученом файле найдите все дампы с вашим методом. Смотрите на чем чаще всего он висит. На JDBC, на socket write или sendData
...
Рейтинг: 0 / 0
23.10.2013, 16:57:23
| Ответить | Цитировать | Написать  
Долгое закрытие JDBC
    #38438690
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Blazkowicz
Участник
GorloPavelПотому что в логике сервера с одним потоком может взаимодействовать только один поток. Включая вызывать его sendData со своими данными. Не понял как sendData одного потока может блокировать sendData во всех потоках?
Всё, понял. Там не массовая рассылка на 9К сессий, а лишь на одного юзера? Т.е. sendData вызывается всего несколько раз?
...
Рейтинг: 0 / 0
23.10.2013, 16:59:43
| Ответить | Цитировать | Написать  
Долгое закрытие JDBC
    #38438697
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Blazkowicz
Участник
У вас лог всего на 3 точки. А нужно было больше делать
- начало метода
- после получения connection
- после запуска запроса
- после цикла
- после close()
И выяснить кто из них действительно тормозил.
...
Рейтинг: 0 / 0
23.10.2013, 17:02:56
| Ответить | Цитировать | Написать  
Долгое закрытие JDBC
    #38438705
GorloPavel
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GorloPavel
Участник
BlazkowiczGorloPavelПотому что в логике сервера с одним потоком может взаимодействовать только один поток. Включая вызывать его sendData со своими данными. Не понял как sendData одного потока может блокировать sendData во всех потоках?
Всё, понял. Там не массовая рассылка на 9К сессий, а лишь на одного юзера? Т.е. sendData вызывается всего несколько раз?
Нет. Объясню. Есть к примеру два ПК между ними устанавливается связь средством удаленного сервера к которому они оба подключаются. Они могут инициировать вызов функций на сервере(авторизация, редактирование списка контактов и т.д) так и передавать данные друг другу(псевдо peer-to-peer) если невозможно подключение напрямую. В случае если они передают данные друг другу через сервер, то они вызывают перегруженный метод sendData(byte[]) друг у друга при получении данных который шлет пакет без изменений.
...
Рейтинг: 0 / 0
23.10.2013, 17:08:59
| Ответить | Цитировать | Написать  
Долгое закрытие JDBC
    #38438716
GorloPavel
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GorloPavel
Участник
Так же сам сервер может им обоим слать кое какие пакеты. Вот это кокраз тот случай. Хранимая процедура возвращает id сессий которым нужно разослать этот пакет. Грубо говоря у вас в списке есть 10 контактов и у меня есть 10 контактов. У вас и у меня 5 одинаковых контактов. Вдруг эти пять контактов становятся онлайн. Сервер выясняет кого нужно уведомить и рассылает данный пакет.
...
Рейтинг: 0 / 0
23.10.2013, 17:12:47
| Ответить | Цитировать | Написать  
Долгое закрытие JDBC
    #38438721
GorloPavel
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GorloPavel
Участник
Следовательно этот пакет получите только вы и я.
...
Рейтинг: 0 / 0
23.10.2013, 17:14:31
| Ответить | Цитировать | Написать  
Долгое закрытие JDBC
    #38438725
GorloPavel
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GorloPavel
Участник
Вернее в данном случае мы получаем пакет от одного из ПК и рассылаем его нужным ПК у которых в списках он есть.
...
Рейтинг: 0 / 0
23.10.2013, 17:16:49
| Ответить | Цитировать | Написать  
Долгое закрытие JDBC
    #38438728
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
А эту задачу нельзя было решать на уровне триггеров на users_online, hosts_online?
...
Рейтинг: 0 / 0
23.10.2013, 17:18:09
| Ответить | Цитировать | Написать  
Долгое закрытие JDBC
    #38438754
GorloPavel
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GorloPavel
Участник
maytonА эту задачу нельзя было решать на уровне триггеров на users_online, hosts_online?
Я к примеру написал ситуацию. Чтобы было понятно зачем так много потоков. А по вопросу... В данном случае сервер рассылает нужным клиентам не информацию о online. Тут триггера не помогут.
...
Рейтинг: 0 / 0
23.10.2013, 17:30:02
| Ответить | Цитировать | Написать  
Долгое закрытие JDBC
    #38438933
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Basil A. Sidorov
Участник
Подход неправильный. Соединение должно возвращаться в пул не "максимально быстро", а "если больше не требуется".
Ваш запрос выполняется или "постоянно" или "очень часто", поэтому надо взять соединение, подготовить запрос и выполнять его с нужными параметрами до тех пор, "пока работает" и "нет ошибок выполнения".
...
Рейтинг: 0 / 0
23.10.2013, 19:25:25
| Ответить | Цитировать | Написать  
Долгое закрытие JDBC
    #38438998
Atum1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Atum1
Участник
Вопрос номер один -что за сервер?

Какая архитектура , какие либы используете ?

какой подход : spring или ejb ?

какой используется pool соединений и есть ли он вообще? как он настроен?

что вам дает использование хранимой процедуры ?

Перейдите на select - с параметрами только чтение.

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

Какое количество коннектов допускается к базе? сколько из них задействовано ?
...
Рейтинг: 0 / 0
23.10.2013, 20:31:46
| Ответить | Цитировать | Написать  
Долгое закрытие JDBC
    #38439293
maxkar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
maxkar
Участник
GorloPavelФункция sendData

У вас ввод/вывод блокирующий. Выходного буфера для sendMessage может не хватить, клиент отвалился - вы будете висеть в ожидании записи/таймаута.

GorloPavelКоличество возвращаемых записей в большинстве случаев не более 2-5.
Ну вот и выберите их сначала в список. Закройте соединение с базой. А потом по списку уже начинайте уведомлять.

При таком количестве вместо списка еще рекомендуется какой-нибудь map. Тогда вместо 20000 итераций у вас будет 2-5. Но проблему с тем, что запись к определенному клиенту может заблокироваться на выводе, это не решит.
...
Рейтинг: 0 / 0
24.10.2013, 09:34:22
| Ответить | Цитировать | Написать  
Долгое закрытие JDBC
    #38439780
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
maxkarНу вот и выберите их сначала в список. Закройте соединение с базой. А потом по списку уже начинайте уведомлять.
+1
вместо параллелизма в юзверях, выстроить параллелизм в БД -- SendData
...
Рейтинг: 0 / 0
24.10.2013, 13:16:09
| Ответить | Цитировать | Написать  
59 сообщений из 59, показаны все 3 страниц
  все  
Форумы / Java [игнор отключен] [закрыт для гостей] / Долгое закрытие JDBC
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?all=1&fid=59&tid=2128352]:
 0ms
get settings:
 9ms
get forum list:
 9ms
check forum access:
 2ms
check topic access:
 2ms
track hit:
 180ms
get topic data:
 11ms
get forum data:
 2ms
get page messages:
 105ms
get tp. blocked users:
 1ms
others: 234ms
total:  555ms
созд. / загр.: 555ms
x
x
Закрыть


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