<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>OpenText Analytics Database 26.2.x – Managing system resource usage</title>
    <link>/en/admin/managing-db/managing-workloads/managing-system-resource-usage/</link>
    <description>Recent content in Managing system resource usage on OpenText Analytics Database 26.2.x</description>
    <generator>Hugo -- gohugo.io</generator>
    
	  <atom:link href="/en/admin/managing-db/managing-workloads/managing-system-resource-usage/index.xml" rel="self" type="application/rss+xml" />
    
    
      
        
      
    
    
    <item>
      <title>Admin: Managing sessions</title>
      <link>/en/admin/managing-db/managing-workloads/managing-system-resource-usage/managing-sessions/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>/en/admin/managing-db/managing-workloads/managing-system-resource-usage/managing-sessions/</guid>
      <description>
        
        
        &lt;p&gt;Vertica provides several methods for database administrators to view and control sessions. The methods vary according to the type of session:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;
&lt;p&gt;External (user) sessions are initiated by vsql or programmatic (ODBC or JDBC) connections and have associated client state.&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;Internal (system) sessions are initiated by Vertica and have no client state.&lt;/p&gt;
&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id=&#34;configuring-maximum-sessions&#34;&gt;Configuring maximum sessions&lt;/h2&gt;
&lt;p&gt;The maximum number of per-node user sessions is set by the configuration parameter &lt;code&gt;MaxClientSessions&lt;/code&gt; parameter, by default 50. You can set &lt;code&gt;MaxClientSessions&lt;/code&gt; parameter to any value between 0 and 1000. In addition to this maximum, Vertica also allows up to five administrative sessions per node.&lt;/p&gt;
&lt;p&gt;For example:&lt;/p&gt;
&lt;pre tabindex=&#34;0&#34;&gt;&lt;code&gt;=&amp;gt; ALTER DATABASE DEFAULT SET MaxClientSessions = 100;
&lt;/code&gt;&lt;/pre&gt;
&lt;div class=&#34;alert admonition note&#34; role=&#34;alert&#34;&gt;
&lt;h4 class=&#34;admonition-head&#34;&gt;Note&lt;/h4&gt;

If you use the Administration Tools &amp;quot;Connect to Database&amp;quot; option, Vertica will attempt connections to other nodes if a local connection does not succeed. These cases can result in more successful &amp;quot;Connect to Database&amp;quot; commands than you would expect given the &lt;code&gt;MaxClientSessions&lt;/code&gt; value.

&lt;/div&gt;
&lt;h2 id=&#34;viewing-sessions&#34;&gt;Viewing sessions&lt;/h2&gt;
&lt;p&gt;The system table 
&lt;code&gt;&lt;a href=&#34;../../../../../en/sql-reference/system-tables/v-monitor-schema/sessions/#&#34;&gt;SESSIONS&lt;/a&gt;&lt;/code&gt; contains detailed information about user sessions and returns one row per session. Superusers have unrestricted access to all database metadata. Access for other users varies according to their &lt;a href=&#34;../../../../../en/admin/db-users-and-privileges/db-privileges/db-object-privileges/#Metadata&#34;&gt;privileges&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;&lt;a name=&#34;Interrup&#34;&gt;&lt;/a&gt;&lt;/p&gt;
&lt;h2 id=&#34;interrupting-and-closing-sessions&#34;&gt;Interrupting and closing sessions&lt;/h2&gt;
&lt;p&gt;You can interrupt a running statement with the Vertica function 
&lt;code&gt;&lt;a href=&#34;../../../../../en/sql-reference/functions/management-functions/session-functions/interrupt-statement/#&#34;&gt;INTERRUPT_STATEMENT&lt;/a&gt;&lt;/code&gt;. Interrupting a running statement returns a session to an idle state:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;
&lt;p&gt;No statements or transactions are running.&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;No locks are held.&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;The database is doing no work on behalf of the session.&lt;/p&gt;
&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;Closing a user session interrupts the session and disposes of all state related to the session, including client socket connections for the target sessions. The following Vertica functions close one or more user sessions:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;

&lt;code&gt;&lt;a href=&#34;../../../../../en/sql-reference/functions/management-functions/session-functions/close-session/#&#34;&gt;CLOSE_SESSION&lt;/a&gt;&lt;/code&gt;
&lt;/li&gt;
&lt;li&gt;

&lt;code&gt;&lt;a href=&#34;../../../../../en/sql-reference/functions/management-functions/session-functions/close-all-sessions/#&#34;&gt;CLOSE_ALL_SESSIONS&lt;/a&gt;&lt;/code&gt;
&lt;/li&gt;
&lt;li&gt;

&lt;code&gt;&lt;a href=&#34;../../../../../en/sql-reference/functions/management-functions/session-functions/close-user-sessions/#&#34;&gt;CLOSE_USER_SESSIONS&lt;/a&gt;&lt;/code&gt;
&lt;/li&gt;
&lt;li&gt;

&lt;code&gt;&lt;a href=&#34;../../../../../en/sql-reference/functions/management-functions/db-functions/shutdown/#&#34;&gt;SHUTDOWN&lt;/a&gt;&lt;/code&gt;
&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;&lt;code&gt;SELECT&lt;/code&gt; statements that call these functions return after the interrupt or close message is delivered to all nodes. The function might return before Vertica completes execution of the interrupt or close operation. Thus, there might be a delay after the statement returns and the interrupt or close takes effect throughout the cluster. To determine if the session or transaction ended, query the &lt;code&gt;SESSIONS&lt;/code&gt; system table.&lt;/p&gt;
&lt;p&gt;In order to shut down a database, you must first close all user sessions. For more about database shutdown, see &lt;a href=&#34;../../../../../en/admin/operating-db/stopping-db/#&#34;&gt;Stopping the database&lt;/a&gt;.&lt;/p&gt;

      </description>
    </item>
    
    <item>
      <title>Admin: Managing load streams</title>
      <link>/en/admin/managing-db/managing-workloads/managing-system-resource-usage/managing-load-streams/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>/en/admin/managing-db/managing-workloads/managing-system-resource-usage/managing-load-streams/</guid>
      <description>
        
        
        &lt;p&gt;You can use system table &lt;a href=&#34;../../../../../en/sql-reference/system-tables/v-monitor-schema/load-streams/#&#34;&gt;LOAD_STREAMS&lt;/a&gt; to monitor data as it is loaded on your cluster. Several columns in this table showmetrics for each load stream on each node, including the following:&lt;/p&gt;

&lt;table class=&#34;table table-bordered&#34; &gt;



&lt;tr&gt; 

&lt;th &gt;
Column name&lt;/th&gt; 

&lt;th &gt;
Value...&lt;/th&gt;&lt;/tr&gt;

&lt;tr&gt; 

&lt;td &gt;
&lt;code&gt;ACCEPTED_ROW_COUNT&lt;/code&gt;&lt;/td&gt; 

&lt;td &gt;
Increases during parsing, up to the maximum number of rows in the input file.&lt;/td&gt;&lt;/tr&gt;

&lt;tr&gt; 

&lt;td &gt;
&lt;code&gt;PARSE_COMPLETE_PERCENT&lt;/code&gt;&lt;/td&gt; 

&lt;td &gt;




&lt;p&gt;Remains zero (0) until all named pipes return an EOF. While COPY awaits an EOF from multiple pipes, it can appear to be hung. However, before canceling the COPY statement, check your &lt;a href=&#34;../../../../../en/admin/monitoring/monitoring-linux-resource-usage/&#34;&gt;system CPU and disk accesses&lt;/a&gt; to determine if any activity is in progress.&lt;/p&gt;
&lt;p&gt;In a typical load, the &lt;code&gt;PARSE_COMPLETE_PERCENT&lt;/code&gt; value can either increase slowly or jump quickly to 100%, if you are loading from named pipes or STDIN.&lt;/p&gt;
&lt;/td&gt;&lt;/tr&gt;

&lt;tr&gt; 

&lt;td &gt;
&lt;code&gt;SORT_COMPLETE_PERCENT&lt;/code&gt;&lt;/td&gt; 

&lt;td &gt;
Remains at 0 when loading from named pipes or STDIN. After &lt;code&gt;PARSE_COMPLETE_PERCENT&lt;/code&gt; reaches 100 percent, &lt;code&gt;SORT_COMPLETE_PERCENT&lt;/code&gt; increases to 100 percent.&lt;/td&gt;&lt;/tr&gt;&lt;/table&gt;

&lt;p&gt;Depending on the data sizes, a significant lag can occur between the time &lt;code&gt;PARSE_COMPLETE_PERCENT&lt;/code&gt; reaches 100 percent and the time &lt;code&gt;SORT_COMPLETE_PERCENT&lt;/code&gt; begins to increase.&lt;/p&gt;


      </description>
    </item>
    
  </channel>
</rss>
