Come raffreddare a liquido la GPU: la mia prova col Kraken X63

Oggi l’elemento principale, oltre che il piu costoso, di qualsiasi PC da Gaming e’ sicuramente la GPU… ed e’ purtroppo anche il piu rumoroso durante i carichi di lavoro elevati.

Nel mio caso, avendo il PC in salotto, questa dava non poco fastidio a chi mi stava intorno quando lo usavo a lungo, pertanto ho deciso di procedere ad un intervento drastico per abbassarne la rumorosita’.

Come tutti sappiamo le schede grafiche, almeno nella loro versione stock, dispongono in genere di dissipatore ad aria corredato da ottime ventole di raffreddamento. Queste ultime sono progettate per raffreddare il dissipatore, e quindi la scheda, mantenendola costantemente entro il giusto range termico operativo…. tuttavia lo fanno spesso generando non poco rumore.

Tale rumore e’ dovuto alla rotazione delle ventole che, per raggiungere lo scopo, devono raggiungere una velocita’ sufficente a muovere l’aria necessaria a raffreddare la scheda. Nel mio caso la mia Gigabyte RTX 2080 OC ne aveva ben 3, grazie al dissapatore WindForce…. ben fatto ed efficace, certo…. ma secondo me rumoroso sui carichi elevati.

Come risolvere quindi il problema?

La soluzione che ho scelto e’ stata quella di sostitiuire il dissipatore della scheda con un dissipatore a liquido di tipo all-in-one, l’NZXT Kraken X63 corredato dall’adattatore NZXT Kraken G12, necessario per il montaggio sulla scheda.
In ultimo, per l’applicazione del dissipatore, ho scelto la pasta termica Artic MX-5

Questo approfittando del fatto che la scheda stava andando fuori garanzia pertanto potevo arrischiarmi a smontarla sapendo che, in ogni caso, il supporto in caso di guasto futuro al prodotto era comunque gia scaduto.

E’ importante infatti tenere presente questo punto proseguendo nell’articolo… Tutti i danni dovuti ad operazioni di smontaggio della scheda NON rientrano tra quelli coperti dalla garanzia del prodotto…. pertanto e’ bene ricordare che tutti i passaggi descritti di seguito, se vorrete anche voi applicare una soluzione simile, sono da farsi a vostro rischio e pericolo.
Alcuni produttori sono piu tolleranti di altri in quanto vanno a constatare il tipo di danno prima di rifiutare un eventuale rimborso in garanza per malfunzionamento…. ma e’ bene chiarirsi le idee prima di applicare questo tipo di soluzione. Anzi…. scriviamolto anche in un bel disclaimer molto chiaro, giusto per chiarirci bene l’idea….

ATTENZIONE: Lo smontaggio di una scheda video implica la caduta di tutti i diritti di garanzia e supporto.

Chiarito questo punto, come dicevo, passare ad un dissipatore a liquido e’ stata la mia scelta per ridurre la rumorosita’. Perche’?
Un dissipatore a liquido e’ costituito da un blocco da montarsi in prossimita del processore da raffreddare con pompa integrata (nel caso dei modelli all-in-one come questo). Questo blocco fa scorrere liquido di raffreddamento verso un radiatore. Il radiatore e’ a sua volta raffreddato da una serie di ventole…. ma queste hanno il grosso vantaggio, trovandosi in una zona ben piu ampia del case, di poter essere molto piu grandi di quelle che si potrebbero mettere su una scheda video.
Il vantaggio e’ che possono girare molto piu lentamente garantendo quindi una rumorosita complessiva ridotta rispetto alla soluzione stock.
La rumorosita’ quindi e’ azzerata?
No, non lo e’ attenzione…. teniamolo bene presente da subito. Non si tratta di una soluzione a rumore zero in quanto la pompa e le ventole producono comunque un rumore…. ma quest’ultimo e’ tendezialmente inferiore in caso di carichi elevati rispetto a quello che avreste dalle ventole standard di una scheda video.
Certo….ovviamente questo vale se avete ben dimensionato la soluzione con un radiatore di dimensioni adeguate. Per questo punto pero’, prima di fare scelte, vi raccomando comunque sempre di controllare i valori di rumorosita’ indicati dal produttore sia per la vostra scheda che per il dissipatore a liquido che state prendendo in considerazione.

Una volta ricevuti tutti i componenti sono quindi passato allo smontaggio del precedente dissipatore… la parte che probabilmente temevo maggiormente con la paura di fare qualche danno. Tuttavia, lavorando con delicatezza e calma, l’operazione e’ stata piu semplice del previsto. Rimosse le viti, facendo attenzione a staccare il vecchio dissipatore un po’ alla volta facendo solo minimamente leva dove necessario e staccando il connettore di alimentazione del dissipatore, i due componenti si sono separati senza troppi problemi.

Scheda e dissipatore separati

Il passo successivo e’ stato quello di rimuovere tutti gli adesivi (facendo attenzione a riposizionarli sulla scheda per eventuale rimontaggio del dissipatore, senza perderli) per poi passare alla pulizia della GPU con alchool e cotone idrofilo. I puristi mi scuseranno in quanto, nei laboratori che fanno questo genere di lavori, ci sono strumenti sicuramente piu appropriati (alchool isopropilico, strumenti di rimozione migliori…e sicuramente anche sistemi antistatici del caso) tuttavia questo era quello che avevo a disposizione e ha comunque fatto molto bene il suo mestiere

A questo punto quindi ho messo la pasta termica sul processore della scheda e sono passato al montaggio del dissipatore sulla scheda con l’adattatore G12. Qui il timore era inferiore ma comunque l’attenzione e’ stata molto alta temendo comunque di non farli aderire bene l’uno sull’altro.

Verifica di contatto corretto e uniforme tra blocco e GPU

Messe e tirate un po’ le viti pero’…. il grosso era fatto!

Scheda e AIO finalmente montati

Fatto questo sono passato al montaggio nel case (il mio NZXT H500) che seguendo bene le istruzioni non e’ stato difficile…. tuttavia raccomando anche qui di fare le cose con molta calma a chi volesse cimentarsi, perche’ il posizionamento richiede un po’ di attenzione.
I tubi che portano al radiatore non sono lunghissimi…. hanno diciamo “la misura giusta”. Pertanto farli passare nel modo corretto e’ indispensabile per riuscire a posizionare il radiatore all’interno del case.

Vista interna del case. Radiatore montato sulla destra in posizione anteriore con ventole girate verso l’esterno. A sinistra la scheda con il blocco orientato verso il basso.

Una volta connessi i vari cavi delle pompa oltre che i cavetti delle ventole ho provato ad avviare il tutto….che fortunosamente e’ partito senza probblemi facendomi tirare il classico sospiro di sollievo.
A quel punto il passo successivo e’ stata l’installazione e la configurazione del software NZXT CAM per gestire e monitorare il Kraken.

Di seguito pero’ non era tutto finito.
E’ importante ricordare che ho dovuto passare un bel po’ di tempo per regolare bene la velocita’ delle ventole del case (collegate alla motherboard), e la velocita ‘dell’AIO (il Kraken) anch’esso collegato alla Mobo per adeguare tutto il sistema al nuovo componente aggiunto.
Riducendo la temperatura complessiva nel case infatti ho potuto quindi ridure anche la velocita’ delle altre ventole raggiungendo quindi temperature di esercizio basse associate a rumorosita’ ridotta. Un buon esercizio fatto tenendo bene d’occhio i valori di temperatura dei vari componenti tramite la soluzione di monitoring che gia vi ho descritto nell’articolo che trovate QUI.
Un altro punto di attenzione e’ stato configurare il Kraken in modo che la sua velocita’ fosse legat alla temperatura della GPU e non a quella della CPU (che e’ li default). Questo in particolare e’ una configurazione abbastanza immediata che (ora che sapete che esiste… :)) trovate nel pannello di controllo del software NZXT CAM.

E il rumore? Nei test fatti con il mio fonometro ho registrato una riduzione di almeno -4dB… nella rumorosita’ complessiva (che non sono pochi!!) che migliora ulteriormente nelle situazioni di alto carico. Questo si associa ad un drastico abbassamento della temperatura di almeno 20 gradi per la GPU. Sono quelle cose che ti fanno dire…. Perche’ non l’ho fatto prima???

Conclusioni
Se siete arrivati fin qui a leggere questo articolo la conclusione sembra ovvia. Abbattimento di rumore e temperatura sono tutti scopi pienamente raggiunti.
Ma lo consiglierei a tutti?
La risposta un po’ meno scontata e che va ovviamente argomentata e’…“dipende”.
Nel mio caso la scheda video era uscita dalla garanzia pertanto non avevo timore di perdere il supporto in caso di problemi col prodotto. Ma se cosi non fosse stato magari avrei quantomeno aspettato…anche perche’ le operazioni di smontaggio e montaggio che avete visto non sono poche ed era la prima volta che facevo questo lavoro (anche se ho altre esperienze del genere alle spalle).
Poi, come per tutte le cose, dipende da quanto siete confidenti nel fare questo tipo di operazioni rispetto al vostro portafogli. Rompere una scheda da 700 euro (quando l’ho presa… ormai vale molto meno….) mentre montate un dissipatore e’ una cosa che non vi fa stare tranquilli? Allora non fate un intervento del genere.
Non avete dimestichezza ma avete un fornitore che fa per voi questo lavoro e magari vi garantisce anche la garanzia? Allora fatelo, i vantaggi sono indiscussi!
Fatte tutte queste premesse, comunque, la mia personale esperienza che condivido e’ che sono sicuramente estremamente soddisfatto sia dei prodotti che del risultato raggiunto.

Come vedete i fattori da valutare sono diversi ma spero comunque di avervi dato, con la descrizione della mia esperienza, tutti gli elmenti utili per poter pianificare la vostra scelta.
Ma sopratutto…. se doveste decidere di imbarcarvi in questa attivita’….divertitevi perche’ il tuning e’ una di quelle cose che, se siete arrivati fin qui a leggere, sono sicuro da estremamente soddisfazione anche a voi come ne da a me….e questo non a lavoro finito ma proprio mentre lo pianificate, fate le vostre scelte e poi magari decidete di procedere.

Quindi, in ogni caso… buon viaggio 🙂

p.s. un grazie all’amico Goozo (al secolo Daniele :)) che si e’ lanciato per primo in questa attivita’ sul suo pc e mi ha convinto che era fattibile senza troppi rischi.

How to improve mysql performance using CACHING

A deep analisys of a performance bottleneck could be long and is based on different kind of data (OS metrics, IO performance tests, DB wait stats and so on…). Before starting with this (or simply after a new delivery) some simple checks could help you to correct rapidly some of the common (and bigger) bottlenecks you can find in a low-performance installation.
One of this is cache sizing.

A cache disabled or not correctly configured is a common reason of low-performance problems.
MySQL engine use a result-caching to improve query speed. A query result is cached in memory to avoid slow IO reading operations. Mysql use the query_cache_size parameter to size the engine cache. A result is saved in the cache only if it’s larger then the query_cache_min_res_unit parameter but smaller then the query_cache_limit.

A query result is kept in memory until:
– the result is valid (data are not modified)
– there are no more-used results using spaces in cache dedicated memory

A good sizing of cache instance parameters is based on instance activity. My suggestion are:
– Start with a simple configuration using system memory available (avoiding paging). note: by default mysql cache is DISABLED
– Start keeping query_cache_min_res_unit little.
– Check istance metrics after some days of normal database activity to understand how you can tune better cache parameters

This is an example of an installed configuration:

mysql> show variables like '%query_cache%';
+------------------------------+----------+
| Variable_name                | Value    |
+------------------------------+----------+
| have_query_cache             | YES      |
| query_cache_limit            | 2097152  |
| query_cache_min_res_unit     | 4096     |
| query_cache_size             | 33554432 |
| query_cache_type             | ON       |
+------------------------------+----------+
5 rows in set (0.00 sec)

After some days of normal instance activity start watching some metrics to understand whats heppening.
Those values are self explained

mysql> show status like 'QCache%';
+-------------------------+----------+
| Variable_name           | Value    |
+-------------------------+----------+
| Qcache_free_blocks      | 957      |
| Qcache_free_memory      | 15523704 |
| Qcache_hits             | 1978478  |
| Qcache_inserts          | 132298   |
| Qcache_lowmem_prunes    | 6037     |
| Qcache_not_cached       | 5969     |
| Qcache_queries_in_cache | 3389     |
| Qcache_total_blocks     | 8396     |
+-------------------------+----------+
8 rows in set (0.00 sec)

Talking about performances there are no “top configuration” usable. You have to work with users and system integrators to understand:
– Any application suggested cache configuration
– In low performance situations: what is the performance target ?
– Are there any test query usable to test configuration tuning?

For a deeper explanation of all mysql cache parameters start from here: http://dev.mysql.com/doc/refman/5.6/en/query-cache.html

Anayze SQL default trace to investigate instance events

Quering default trace is the best way to investigate unusual or critical events heppened in SQL server and not logged in errorlog files.
It’s not difficult to find useful informations there but the trace is full of codes to translate to make it more readable and useful. This is my query, based on sys.fn_trace_gettable function and sys.trace_events system table.

DECLARE @TraceFileName NVARCHAR(512)  --Find the trace file name
SELECT @TraceFileName = path
  FROM sys.traces
 WHERE id = 1
 
 SELECT StartTime,  --then we can quering, translating the EventClass  
	TE.name as EventClass , 
    TextData,  
    HostName,  
    ApplicationName,  
    LoginName,  
    SPID,           --this is the SPID of the session:   
    ObjectName      --can be used for following analysis 	
   FROM sys.fn_trace_gettable(@TraceFileName,default) TG
   left join
   sys.trace_events TE on TG.EventClass=TE.trace_event_id
   where TE.name is not null

If you are looking for the query that generated an event (log file grow, deleted object and so on…) you can look for it quering the inputbuffer for the SPID.
NOTE: the SPID can be re-used during the instance life and the inputbuffer is cleaned and re-used for following queries

dbcc inputbuffer([SPID])

The following is the full list of events available to filter in the previous query if you need to monitor a particular kind of event.
Not all are used in the default trace. If you need not traced event you have to create a custom trace.

select trace_event_id,name from sys.trace_events 

trace_event_id name
-------------- -------------------------------
10             RPC:Completed
11             RPC:Starting
12             SQL:BatchCompleted
13             SQL:BatchStarting
14             Audit Login
15             Audit Logout
16             Attention
17             ExistingConnection
18             Audit Server Starts And Stops
19             DTCTransaction
20             Audit Login Failed
21             EventLog
22             ErrorLog
23             Lock:Released
24             Lock:Acquired
25             Lock:Deadlock
26             Lock:Cancel
27             Lock:Timeout
28             Degree of Parallelism
33             Exception
34             SP:CacheMiss
35             SP:CacheInsert
36             SP:CacheRemove
37             SP:Recompile
38             SP:CacheHit
40             SQL:StmtStarting
41             SQL:StmtCompleted
42             SP:Starting
43             SP:Completed
44             SP:StmtStarting
45             SP:StmtCompleted
46             Object:Created
47             Object:Deleted
50             SQLTransaction
51             Scan:Started
52             Scan:Stopped
53             CursorOpen
54             TransactionLog
55             Hash Warning
58             Auto Stats
59             Lock:Deadlock Chain
60             Lock:Escalation
61             OLEDB Errors
67             Execution Warnings
68             Showplan Text (Unencoded)
69             Sort Warnings
70             CursorPrepare
71             Prepare SQL
72             Exec Prepared SQL
73             Unprepare SQL
74             CursorExecute
75             CursorRecompile
76             CursorImplicitConversion
77             CursorUnprepare
78             CursorClose
79             Missing Column Statistics
80             Missing Join Predicate
81             Server Memory Change
82             UserConfigurable:0
83             UserConfigurable:1
84             UserConfigurable:2
85             UserConfigurable:3
86             UserConfigurable:4
87             UserConfigurable:5
88             UserConfigurable:6
89             UserConfigurable:7
90             UserConfigurable:8
91             UserConfigurable:9
92             Data File Auto Grow
93             Log File Auto Grow
94             Data File Auto Shrink
95             Log File Auto Shrink
96             Showplan Text
97             Showplan All
98             Showplan Statistics Profile
100            RPC Output Parameter
102            Audit Database Scope GDR Event
103            Audit Schema Object GDR Event
104            Audit Addlogin Event
105            Audit Login GDR Event
106            Audit Login Change Property Event
107            Audit Login Change Password Event
108            Audit Add Login to Server Role Event
109            Audit Add DB User Event
110            Audit Add Member to DB Role Event
111            Audit Add Role Event
112            Audit App Role Change Password Event
113            Audit Statement Permission Event
114            Audit Schema Object Access Event
115            Audit Backup/Restore Event
116            Audit DBCC Event
117            Audit Change Audit Event
118            Audit Object Derived Permission Event
119            OLEDB Call Event
120            OLEDB QueryInterface Event
121            OLEDB DataRead Event
122            Showplan XML
123            SQL:FullTextQuery
124            Broker:Conversation
125            Deprecation Announcement
126            Deprecation Final Support
127            Exchange Spill Event
128            Audit Database Management Event
129            Audit Database Object Management Event
130            Audit Database Principal Management Event
131            Audit Schema Object Management Event
132            Audit Server Principal Impersonation Event
133            Audit Database Principal Impersonation Event
134            Audit Server Object Take Ownership Event
135            Audit Database Object Take Ownership Event
136            Broker:Conversation Group
137            Blocked process report
138            Broker:Connection
139            Broker:Forwarded Message Sent
140            Broker:Forwarded Message Dropped
141            Broker:Message Classify
142            Broker:Transmission
143            Broker:Queue Disabled
144            Broker:Mirrored Route State Changed
146            Showplan XML Statistics Profile
148            Deadlock graph
149            Broker:Remote Message Acknowledgement
150            Trace File Close
151            Database Mirroring Connection
152            Audit Change Database Owner
153            Audit Schema Object Take Ownership Event
154            Audit Database Mirroring Login
155            FT:Crawl Started
156            FT:Crawl Stopped
157            FT:Crawl Aborted
158            Audit Broker Conversation
159            Audit Broker Login
160            Broker:Message Undeliverable
161            Broker:Corrupted Message
162            User Error Message
163            Broker:Activation
164            Object:Altered
165            Performance statistics
166            SQL:StmtRecompile
167            Database Mirroring State Change
168            Showplan XML For Query Compile
169            Showplan All For Query Compile
170            Audit Server Scope GDR Event
171            Audit Server Object GDR Event
172            Audit Database Object GDR Event
173            Audit Server Operation Event
175            Audit Server Alter Trace Event
176            Audit Server Object Management Event
177            Audit Server Principal Management Event
178            Audit Database Operation Event
180            Audit Database Object Access Event
181            TM: Begin Tran starting
182            TM: Begin Tran completed
183            TM: Promote Tran starting
184            TM: Promote Tran completed
185            TM: Commit Tran starting
186            TM: Commit Tran completed
187            TM: Rollback Tran starting
188            TM: Rollback Tran completed
189            Lock:Timeout (timeout > 0)
190            Progress Report: Online Index Operation
191            TM: Save Tran starting
192            TM: Save Tran completed
193            Background Job Error
194            OLEDB Provider Information
195            Mount Tape
196            Assembly Load
198            XQuery Static Type
199            QN: Subscription
200            QN: Parameter table
201            QN: Template
202            QN: Dynamics
212            Bitmap Warning
213            Database Suspect Data Page
214            CPU threshold exceeded
215            PreConnect:Starting
216            PreConnect:Completed
217            Plan Guide Successful
218            Plan Guide Unsuccessful
235            Audit Fulltext

How to make your databases smaller and faster: find unused indexes

It’s a boring job but sometimes a good DBA has to do it.

Applications change and you have to understand what become unuseful in your databases: we are talking about unused indexes. In any SQL server database indexes take up a lot of space and have to be updated every time an application runs an update on an indexed table. You have to rebuild and reorganize them… and you have to backup them, every day.

SQL Server gives you a good instrument to understand which indexes are really used. SYS.DM_DB_INDEX_USAGE_STATS is a dynamic management view used by SQL engine to collect information about this.
The first time a new index is used SQL server adds a new line to this table with many different counters. Those counters are used to collect data about the index every time it’s used. On every instance restart SQL reset index counters.
Querying this view is easy to understad which indexes are really used:
– Indexes not listed here are never used
– Indexes with blank counters are never used since the last instance restart

Those are a queries ready to make this kind of analisys. Remembar that not every application use alway ALL their indexes. Some indexes are used only when specific application functions are turned on. For this reason talk ALWAYS with application support guys before dropping anything.

--Indexes Never Used
DECLARE @dbid INT
SELECT @dbid = DB_ID(DB_NAME())

SELECT OBJECTNAME = OBJECT_NAME(I.OBJECT_ID),
INDEXNAME = I.NAME,
I.INDEX_ID
FROM SYS.INDEXES I
JOIN SYS.OBJECTS O
ON I.OBJECT_ID = O.OBJECT_ID
WHERE OBJECTPROPERTY(O.OBJECT_ID,'IsUserTable') = 1
AND I.INDEX_ID NOT IN (
	SELECT S.INDEX_ID
	FROM SYS.DM_DB_INDEX_USAGE_STATS S
	WHERE S.OBJECT_ID = I.OBJECT_ID
	AND I.INDEX_ID = S.INDEX_ID
	AND DATABASE_ID = @dbid)
	ORDER BY OBJECTNAME,
I.INDEX_ID,
INDEXNAME ASC
GO
--Indexes never used since the last restart
DECLARE @dbid INT
SELECT @dbid = DB_ID(DB_NAME())

SELECT u.*
FROM [sys].[indexes] i
JOIN [sys].[objects] o
ON (i.OBJECT_ID = o.OBJECT_ID)
LEFT JOIN [sys].[dm_db_index_usage_stats] u
ON (i.OBJECT_ID = u.OBJECT_ID)
AND i.[index_id] = u.[index_id]
AND u.[database_id] = @dbid 
WHERE o.[type] <> 'S'
AND i.[type_desc] <> 'HEAP'
AND u.[user_seeks] + u.[user_scans] + u.[user_lookups] = 0
ORDER BY i.indexname asc

Queries to see rapidly what your SQL Server is doing NOW

1) Blocked And Blocking queries.
If this query returns no rows you have no blocked queries in this moment. Run it more then once to see any few-seconds blocking queries. NOTE: This exclude ONLY problems with long-locking running queries. Cumulative short-term locking contentions need other kinds of debug (see point 2)

SELECT 'BLOCKING STATUS' as Controllo,
BlockedSPID=left(blocked.session_id,5) ,
BlockedQuery=convert(varchar(50),blockedsql.text),
BlockingSPID=convert(varchar(50),blocking.session_id),
BlockingQuery=convert(varchar(50),blockingsql.text)
FROM sys.dm_exec_requests blocked
JOIN sys.dm_exec_requests blocking
ON blocked.blocking_session_id = blocking.session_id
CROSS APPLY
(
SELECT *
FROM sys.dm_exec_sql_text(blocked.sql_handle)
) blockedsql
CROSS APPLY
(
SELECT *
FROM sys.dm_exec_sql_text(blocking.sql_handle)
) blockingsql
GO

2) Time-Wait analysis
SQL Server collects informations about time wait events of your instance for every session. Every event (IO,CPU Processing,Locking and so on) is collected and showed in some dynamic management views from instance start/restart. To see what’s heppening now you can reset one af this views and collect for a short time windows events details for debug purpose. To understand the meaning of every SQL Wait Events see: http://msdn.microsoft.com/it-it/library/ms179984.aspx.
Following you can see a good wait analysis script to cross informations for a fast debug (source: http://www.sqlskills.com/blogs/paul/advanced-performance-troubleshooting-waits-latches-spinlocks/)

DBCC SQLPERF ('sys.dm_os_wait_stats', CLEAR); --reset DM view
GO

SELECT
	[owt].[session_id],
	[owt].[exec_context_id],
	[owt].[wait_duration_ms],
	[owt].[wait_type],
	[owt].[blocking_session_id],
	[owt].[resource_description],
	[es].[program_name],
	[est].1,
	[est].[dbid],
	[eqp].[query_plan],
	[es].[cpu_time],
	[es].[memory_usage]
FROM sys.dm_os_waiting_tasks [owt]
INNER JOIN sys.dm_exec_sessions [es] ON
	[owt].[session_id] = [es].[session_id]
INNER JOIN sys.dm_exec_requests [er] ON
	[es].[session_id] = [er].[session_id]
OUTER APPLY sys.dm_exec_sql_text ([er].[sql_handle]) [est]
OUTER APPLY sys.dm_exec_query_plan ([er].[plan_handle]) [eqp]
WHERE [es].[is_user_process] = 1
ORDER BY [owt].[session_id], [owt].[exec_context_id];
GO

3) Open transactions with plan and sql texts
It’s really simple to see informations about current sessions using the old and trusty exec sp_who2 or the dynamic management view sys.dm_exec_requests
But if you need exactly what statements are running and wich plan are they using you need a more complicate query.
This is a good script from http://www.sqlskills.com/blogs/paul/script-open-transactions-with-text-and-plans/ useful to see current transactions with detailed informations about every sessions running.

 SELECT s_tst.[session_id],
   s_es.[login_name] AS [Login Name],
   DB_NAME (s_tdt.database_id) AS [Database],
   s_tdt.[database_transaction_begin_time] AS [Begin Time],
   s_tdt.[database_transaction_log_record_count] AS [Log Records],
   s_tdt.[database_transaction_log_bytes_used] AS [Log Bytes],
   s_tdt.[database_transaction_log_bytes_reserved] AS [Log Rsvd],
   s_est. AS [Last T-SQL Text],
   s_eqp.[query_plan] AS [Last Plan]
FROM sys.dm_tran_database_transactions s_tdt
   JOIN sys.dm_tran_session_transactions s_tst
      ON s_tst.[transaction_id] = s_tdt.[transaction_id]
   JOIN sys.[dm_exec_sessions] s_es
      ON s_es.[session_id] = s_tst.[session_id]
   JOIN sys.dm_exec_connections s_ec
      ON s_ec.[session_id] = s_tst.[session_id]
   LEFT OUTER JOIN sys.dm_exec_requests s_er
      ON s_er.[session_id] = s_tst.[session_id]
   CROSS APPLY sys.dm_exec_sql_text (s_ec.[most_recent_sql_handle]) AS s_est
   OUTER APPLY sys.dm_exec_query_plan (s_er.[plan_handle]) AS s_eqp
ORDER BY [Begin Time] ASC;
GO