welcome: please sign in
location: Diff for "Cluster/Usage"
Differences between revisions 1 and 86 (spanning 85 versions)
Revision 1 as of 2010-06-29 15:26:19
Size: 16259
Editor: aloga
Comment:
Revision 86 as of 2017-02-17 08:58:31
Size: 6969
Editor: aloga
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
= IFCA Datacenter usage guidelines == #acl EditorGroup:read,write,revert Known:read All:read
#pragma section-numbers 2
= IFCA Datacenter usage guidelines =
<<TableOfContents>>
Line 3: Line 6:
'''GRIDUI''' (Grid [[User Interface]]) cluster is the interactive gateway for
the computing resources and projects IFCA is involved on. It is a SSH
[http://www.linuxvirtualserver.org/ LVS], based on [http://linuxsoft.cern.ch/ Scientific Linux Cern]
versions 5. For legacy applications some nodes on Scientific Linux Cern 4 are still available. The login machines are as follow:
{{{#!wiki note
Line 8: Line 8:
<table border="1" cellpadding="2" cellspacing="0" align="center">
<tr align=center bgcolor=#A0A0A0><td>Hostname</td><td>Distribution</td><td>Architecture</td></tr>
<tr><td><strong>gridui.ifca.es</strong></td><td rowspan="2">Scientific Linux CERN SLC release 5.5 (Boron)</td><td rowspan="2" align="center">x86_64</td></tr>
<tr><td><strong>griduisl5.ifca.es</strong></td></tr>
<tr><td><strong>griduisl4.ifca.es</strong></td><td>Scientific Linux CERN SLC release 4.7 (Beryllium)</td><td align="center">i386</td></tr>
</table>
If you find any information that is out-dated, incorrect or incomplete, do not
hesitate to [[#Support|Open a ticket]].
}}}

== Introduction ==

The '''GridUI''' (Grid User Interface) cluster is the interactive gateway to
the [[http://grid.ifca.es|Advanced Computing and e-Science]] resources at
IFCA. This cluster is comprised of a pool of machines reachable through a
single entry point. The connections to the internal machines are managed by
a director node that tries to ensure that proper balancing is made across
the available nodes at a given moment.

Please note that this cluster is ''not intended for the execution of CPU
intensive tasks'', for this purpose use any of the available computing
resources. Every process spawned is limited to a maximum CPU time of 2 hours.
Line 16: Line 26:
[http://en.wikipedia.org/wiki/Secure_Shell Secure Shell]. You can use the standard port 22 or the 22000. [[http://en.wikipedia.org/wiki/Secure_Shell|Secure Shell]]. Outgoing SSH
connections are not allowed by default from this cluster. Inactive SSH
sessions may be closed after 12h. It is highly recommended that you set up
[[Cluster/Usage/SSHKeyManagement| SSH Keys]] for authentication, instead of
using your username and password.
Line 18: Line 32:
Please note that this cluster is not intended for the execution of CPU
intensive tasks, for this purpose use any of the available computing
resources.
  || '''Hostname''' || '''Operating System''' || '''SSH server key fingerprint''' ||
  || `gridui.ifca.es`, `griduisl6.ifca.es` || Scientific Linux 6.X || `29:80:9b:28:e7:8a:00:fe:6c:60:ef:e6:a6:71:33:bd` ||
Line 22: Line 35:
Outgoing SSH connections are not allowed by default from this cluster. Inactive SSH sessions will be closed after 24h. == Authentication and user accounts ==
Line 24: Line 37:
== Authentication == See [[Cluster/SSO]].
Line 26: Line 39:
Authentication is centralized via secured LDAP. All the changes made to a user
account in one node take immediate effect in the whole cluster. There is also
a secured web interface, that allows a user to change his/her details,
available at https://cerbero.ifca.es/. If you need to reset your account
password, please contact the system administrators.
== Access to Scientific Linux 5 machines ==
Line 32: Line 41:
With this username you should be able to access also the ticketing system at
http://support.ifca.es/
After the
[[https://grid.ifca.es/sl5-user-interfaces-deprecation-plan2.html|Scientific
Linux 5 deprecation]] interactive access to Scientific Linux 5 is still
possible trough the batch system. In order to request a SLC5 machine you must
append the complex `scientificlinux5` to your request:
Line 35: Line 47:
== Grid resources == {{{#!highlight console numbers=disable
Line 37: Line 49:
As the cluster is based on several Grid User Interfaces it allows users to access either
[[EGEE-III|EGEE]], [[int.eu.grid|I2G]], [http://www.euforia-project.eu/EUFORIA/ EUFORIA], [https://web.lip.pt/wiki-IBERGRID/ IBERGRID] and [http://grid.csic.es GRID-CSIC] infrastructures. To set up the correct
environment variables, please <code>source</code> any of the environment scripts
located under <code>/gpfs/csic_projects/grid/etc/env/</code>. For example, to
use the I2G infrastructure:
user@cloudprv-10-0:~ $ qsub -l scientificlinux5=true (...)
}}}
Line 43: Line 52:
 % source /gpfs/csic_projects/grid/etc/env/i2g-env.sh If you want an interactive session, append the complex to your `qlogin` request:
Line 45: Line 54:
The available enviroments are: {{{#!highlight console numbers=disable
Line 47: Line 56:
<table border="1" cellpadding="2" cellspacing="0" align="center">
<tr align=center bgcolor=#A0A0A0>
    <td>Filename</td>
    <td>Allows access to</td>
</tr>
<tr>
    <td>euforia-env.{csh,sh}</td>
    <td>EUFORIA</td>
</tr>
<tr>
    <td>i2g-env.{csh,sh}</td>
    <td>int.eu.grid</td>
</tr>
<tr>
    <td>ibergrid-env.{csh,sh}</td>
    <td>IBERGRID and EGI</td>
</tr>
<tr>
    <td>ngi-env.{csh,sh}</td>
    <td>Spanish NGI</td>
</tr>
</table>

More information on seting up the Grid UI is available locally at the
[[DUS: Setting up the User Interface account|corresponding DUS page]].

== PBS Cluster ==

PBS cluster was <strong>decommissioned</strong> in December 2009. Please use the new [[GRIDUI_Cluster#SGE_Cluster|SGE Cluster]] instead.
user@cloudprv-10-0:~ $ qlogin -l scientificlinux5=true (...)
JSV "/nfs4/opt/gridengine/util/resources/jsv/jsv-IFCA.tcl" has been started
JSV "/nfs4/opt/gridengine/util/resources/jsv/jsv-IFCA.tcl" has been stopped
Your job 1822278 ("QLOGIN") has been submitted
waiting for interactive job to be scheduled ...
Your interactive job 1822278 has been successfully scheduled.
Establishing builtin session to host cloudprv-02-9.ifca.es ...
user@cloudprv-02-9:~$ cat /etc/redhat-release
Scientific Linux SL release 5.5 (Boron)
user@cloudprv-02-9:~$
}}}
Line 79: Line 70:
The SGE Cluster is based on <code>Scientific Linux CERN SLC release
5
.5</code> machines, running on x86_64. The exact number or resources
available is shown on the
[http://monitor.ifca.es/ganglia/?c=SGE%20Worker%20Nodes&m=&r=hour&s=descending&hc=4 monitorization page].
The SGE Cluster is based on `Scientific Linux CERN SLC release 6.2` machines, running on x86_64.
Line 84: Line 72:
==== Job submission ==== Local submission is allowed for certain projects. As stated below, there are some shared areas that can be accessed from the computing nodes. The underlying batch system is [[https://arc.liv.ac.uk/trac/SGE|Son of Grid Engine]] 8.0.0d. Refer to the following sources for information:
Line 86: Line 74:
Local submission is allowed for certain projects. As stated below, there are some shared areas that can be accessed from the computing nodes. The underlying batch system is [http://gridengine.sunsource.net/ Sun Grid Engine]. Please note that the syntax for job submission (<tt>qsub</tt>) and monitoring (<tt>qstat</tt>) is similar to the one you might be accustomed to from PBS, but there are important differences. Refer to the following sources for information:  * Using [[/GridEngine]].
 * Some useful [[http://arc.liv.ac.uk/SGE/howto/|HOWTOS]].
 * SGE [[http://grid.ifca.es/wiki/Cluster/SGE/howto/basic_usage.html|basic usage]].
Line 88: Line 78:
* Grid Engine [http://gridengine.sunsource.net/documentation.html documentation page]
* Some useful [http://gridengine.sunsource.net/project/gridengine/howto/howto.html HOWTOS]
* SGE [http://gridengine.sunsource.net/project/gridengine/howto/basic_usage.html basic usage].
{{{#!wiki important
'''IFCA Gridengine documentation has moved'''
Line 92: Line 81:
Users should submit their jobs directly to their project by using <code>qstat -P <project></code>. In other words, instead of:

 % qsub -q lhidra ''jobfile''

you should write (note the dot between the "<tt>l</tt>" and the project name):

 % qsub -P l.hidra ''jobfile''

If a project name is not specified, the job will fall in the ''catch-all low-priority'' queue. Submission without specifying a project is allowed, in order to perform <strong>short</strong> test jobs. However, it is in the best interest of the user to use her project in general, so that the job can take full advantage of more capable (longer, more CPUs, higher priority) queues.

A scratch area is defined for every job as the environment variable <code>$TMPDIR</code>. This area is cleared after the job has exited.

==== Wall Clock time ====

A default wall clock time of 72 hours is enforced by default in all jobs submitted to the cluster. Should you require a higher value, please set it by yourself by requesting a new <code>h_rt</code> value in the form <code>hours:minutes:seconds</code>. Please note that requesting a high value may impact negatively in your job scheduling and execution. Please try to be as accurate as possible when setting this required value. For example, a job requiring 23h should be sent as follows:

 % qsub -P l.hidra -l h_rt=24:00:00 ''jobfile''

==== Memory management ====

When requesting memory for a job you must take into account that per-job memory is limited in the default queues to a [http://en.wikipedia.org/wiki/Resident_set_size Resident Set Size] (h_rss) of 5 GB. If you need to use more memory, you should request the special resource '''''highmem'''''. Please notice that your group may not be able to request that flag by default. If you need to do so, please [http://wiki.ifca.es/e-ciencia/index.php/GRIDUI_Cluster#Support Open a ticket] requesting it.

However, it is <strong>highly recommended</strong> that you tune your memory requirements to some realistic values. Special emphasis is made in the following resources:

* <code>h_rss</code>
* <code>mem_free</code>

====== h_rss ======

The first one (<code>h_rss</code>) refers to the '''hard resident set size limit'''. The batch system will make sure a given job does not consume more memory than the value assigned to that variable. This means that <strong>any job above the requested <code>h_rss</code> limit will be killed (SIGKILL) by the batch system</strong>. It is recommended to request this resource as a top limit for your application. If you expect your job to consume no more than a peak value of 3GB you should request those 3GB as its resident set size limit. This request will not produce a penalty on the scheduling of your jobs.

====== mem_free ======

The second one (<code>mem_free</code>) refers to the free RAM necessary for the job to run. The batch system will allow jobs to run only if sufficient memory (as requested by <code>mem_free</code>) is available for them. It will also subtract that amount of memory from the available resources, once the job is running. This ensures that a node with 16 GB of memory will not run jobs totalling more than 16 GB. The default value is 1.8 GB per slot. Please note that breaking the <code>mem_free</code> limit will not automatically kill your job. Its aim is just to ensure that your job has available the memory you requested. Also note that this value is not intended to be use to reflect the memory peaks of your job. This request will impact the scheduling of your jobs, so it is highly recommended to tune it to fit your application memory usage.

This limit is defined in the <code>/opt/gridengine/default/common/sge_request</code> file. If your application is always expected to use the same values, you can override that file by creating a <code>$HOME/.sge_request</code> file. For further details, please check the <code>sge_request</code> manual page.

====== Examples ======

* A job that needs to have 4 GB of memory assigned to it:

 % qsub -l mem_free=4G ''jobfile''

* A job that might peak at 4 GB, but in its execution normally needs 3 GB:

 % qsub -l h_rss=4G,mem_free=3G ''jobfile''

* A job that might reach 4 GB, and also needs 4 GB:

 % qsub -l h_rss=4G,mem_free=4G ''jobfile''

For serial jobs requiring more than 5 GB of memory, submission requesting the '''''highmem''''' flag is necessary. Using this flag, the <code>h_rss</code> limit will be unset, but the requirement tuning described above still applies. If your group is allowed to request it, and your job needs 20GB of memory, you can request it as follows:

  % qsub -P ''projectname'' -l highmem,mem_free=20G ''jobfile''

* A job that might reach 30 GB and needs 20GB will be submitted as:
 
   % qsub -P ''projectname'' -l highmem,h_rss=30G,mem_free=20G ''jobfile''

* For jobs using [[MPI]], please refer to the [http://wiki.ifca.es/e-ciencia/index.php/GRIDUI_Cluster#Parallel_jobs Parallel job submission] section.

<!--
==== Scratch space ====

The scratch area for the jobs submitted to the cluster is located under <code>/tmp/</code> and is pointed by the <code>$TMPDIR</code> variable.

By default, jobs request a 2GB scratch area. Should you need more space, please use the <code>scract_space</code> in your resource requiremens:

  % qsub -l scratch_space=20G

Please note that this space is dynamic. To check the current disk usage in the nodes you can issue:

  % qhost -F scratch_space
-->

==== Parallel jobs ====

Parallel jobs can be submitted to the parallel environment <code>mpi</code>, specifying the number of slots required. SGE will try to spread them over the available resources.

 % qsub -pe mpi 8 ''jobfile''

Please note that parallel jobs will be routed to queue ''parallel'' (see [[GRIDUI Cluster#Memory management|previous section]]). Also note that access to that queue is restricted to groups having requested it beforehand.

==== Interactive jobs ====

Interactive, short lived and high priority jobs can be send to a special queue <code>interactive.q</code> if the user's project has access to it.

 % qsub -q interactive.q ''jobfile''

Execution on this queue is limited to a maximum of 1h of WALL clock time.

==== Resource quotas ====

Some limits may be enforced by the administrators in a user/group/project basis. To check the current resource quotas, the following command must be issued:

 % qconf -srqs

In order to know the current usage of the quotas defined above, the comand <code>qquota</code> must be used:

 % qquota -P ''<project> ''

==== Advanced reservation ====

Some users and/or projects might request a reservation of a set of resources in advance. This is called an "Advanced Reservation (AR). If your project needs such a reservation you should make a petition using the [http://support.ifca.es/ support helpdesk]. You need to specify the following:

* Start datetime, and end datetime (or duration) of the reservation.
* Duration of your job(s) (i.e. h_rt for the individual jobs).
* Computational resources needed (mem_free, number of slots).

Once the request has been made, the system administrators shall give you the ID(s) of the AR created. You can submit your jobs whenever you want by issuing:

 % qsub -ar ''<reservation_id>'' ''<other_job_options>''

You can submit your job(s) before the AR starts and also once it is started. However, you should take care of the duration of the reservation and your job' duration. If your job execution exceeds either the <code>h_rt</code> that it has requested or the duration of the AR it will be killed by the batch system.

You should also take into account that your reservation might not be created in the date and time that you requested if there are no resources available. In this case, it will be created whenever it is possible. To avoid this, please request your reservations well in advance.

Since the requested and reserved resources cannot be used for other jobs, those requested resources will be used for accounting purposes as if they were resources used by normal jobs (even in the case that the AR is unused). <strong>Please request only the resources that you need</strong>.

If you want to query the existing advance reservations, you can use the <code>qrstat</code> command. To query about an specific advance reservation, you can issue:

 % qrstat -ar ''<reservation_id>''
The specific documentation for IFCA has been moved [[/GridEngine|to a separate section]].
}}}
Line 217: Line 86:
The <tt>home</tt> directories (<code>/home/$USER</code>) are shared between the UIs and the computing nodes. There is a ''projects'' shared area (located at <code>/gpfs/csic_projects/</code>), also accessible from the UI and the computing nodes. If your group does not have this area, please contact the system administrators. The `$HOME` directories are shared between the UIs and the computing nodes. There is a ''projects'' shared area (located at `/gpfs/csic_projects/`), also accessible from the UI and the computing nodes. If your group does not have this area, please open an [[http://support.ifca.es|Incidence ticket]].
Line 219: Line 88:
==== Usage ==== === Usage ===
Line 221: Line 90:
The shared directories <strong>are not intended for scratch</strong>, use the temporal areas of the local filesystems instead. In other words, instruct every job you send to copy the input from the shared directory to the local scratch (<tt>$TMPDIR</tt>), execute all operations there, then copy the output back to some shared area where you will be able to retrieve it comfortably from the UI. The shared directories '''are not intended for scratch''', use the temporal areas of the local filesystems instead. In other words, instruct every job you send to copy the input from the shared directory to the local scratch (`$TMPDIR`), execute all operations there, then copy the output back to some shared area where you will be able to retrieve it comfortably from the UI.
Line 223: Line 92:
As mentioned above, the contents of <tt>$TMPDIR</tt> are removed after job execution. As mentioned above, the contents of `$TMPDIR` are removed after job execution.
Line 225: Line 94:
==== Disk quotas ==== === Disk quotas ===
Line 227: Line 96:
Disk quotas are enabled on both user and projects filesystems. A message with this information should be shown upon login. If you need more quota on your
user space (not in the project shared area), please contact the system administrators explaining your reasons.
Disk quotas are enabled on both user and projects filesystems. A message with this information should be shown upon login. If you need more quota on your user space (not in the project shared area), please contact the system administrators explaining your reasons.
Line 230: Line 98:
If you wish to check your quota at a later time, you can use the commands <code>mmlsquota gpfs_csic</code> (for user quotas) and <code>mmlsquota -g `id -g` gpfs_projects</code> (for group quotas). A script reporting both quotas is located on <code>/gpfs/csic_projects/utils/bin/rep-user-quotas.py</code>. A sample output of the latter could be: If you wish to check your quota at a later time, you can use the commands `mmlsquota gpfs_csic` (for user quotas) and `mmlsquota -g `id -g` gpfs_projects` (for group quotas). A script reporting both quotas is located on `/nfs4/usr/bin/rep-user-quotas.py`. A sample output of the latter could be:
Line 232: Line 100:
 **********************************************************************
                     INFORMATION ABOUT YOUR CURRENT DISK USAGE
 
 USER Used Soft Hard Doubt Grace
 Space (GB): 3.41 20.00 0.00 0.06 none
 Files (x1000): 64 0 0 0 none
 
 GROUP Used Soft Hard Doubt Grace
 Space (GB): 0.00 1000.00 1500.00 0.00 none
 Files (x1000): 0 0 0 0 none
 **********************************************************************
{{{
**********************************************************************
                    INFORMATION ABOUT YOUR CURRENT DISK USAGE
Line 244: Line 104:
For a basic interpretation of this output, note that the "Used" column will tell you about how much disk space you are using, whereas "Soft" denotes the limit this "Used" amount should not exceed. The "Hard" column is the value of the limit "Used" plus "Doubt" should not cross. A healthy disk space management would require that you periodically delete unused files in your <tt>$HOME</tt> directory, keeping its usage below the limits at all times. In the event that the user exceeds a limit, a grace period will be shown in the "Grace" column. If the user does not correct the situation within the grace period, she will be banned from writing to the disk. USER Used Soft Hard Doubt Grace
Space (GB): 3.41 20.00 0.00 0.06 none
Files (x1000): 64 0 0 0 none
Line 246: Line 108:
For further information you can read the [http://www.nersc.gov/vendor_docs/ibm/gpfs/am3admst119.html mmlsquota command manual page]. GROUP Used Soft Hard Doubt Grace
Space (GB): 0.00 1000.00 1500.00 0.00 none
Files (x1000): 0 0 0 0 none
**********************************************************************
}}}
For a basic interpretation of this output, note that the "Used" column will tell you about how much disk space you are using, whereas "Soft" denotes the limit this "Used" amount should not exceed. The "Hard" column is the value of the limit "Used" plus "Doubt" should not cross. A healthy disk space management would require that you periodically delete unused files in your `$HOME` directory, keeping its usage below the limits at all times. In the event that the user exceeds a limit, a grace period will be shown in the "Grace" column. If the user does not correct the situation within the grace period, she will be banned from writing to the disk.
Line 248: Line 115:
== Extra utils == For further information you can read the [[http://www.nersc.gov/vendor_docs/ibm/gpfs/am3admst119.html|mmlsquota command manual page]].
Line 250: Line 117:
Some extra packages as [http://python.org Python 2.6] and [http://software.intel.com/en-us/articles/non-commercial-software-development/ Intel Non-Commercial Compilers] can be found on <code>/gpfs/csic_projects/utils/</code>. == Extra utils/Software ==

Some extra packages can be found at `/nfs4/opt/`. This is the location for
some pieces of software commonly used like:

 * Matlab's like `octave` language for numerical analysis.
 * Data plotting `gnuplot` program.
 * Profiling and debugging `valgrind` tools.
Line 256: Line 130:
Questions, support and/or feedback should be directed through the use the [https://support.ifca.es Helpdesk]. Before opening a new incidence, please check the [[Cluster/FAQ|Frequently Asked Questions page]]
Line 258: Line 132:
<!-- Categories -->
[[Category:Grid Administration]]
[[Category:DUS]]
Questions, support and/or feedback should be directed through the use the [[https://support.ifca.es|Helpdesk]].

----
CategoryUserSupport

IFCA Datacenter usage guidelines

If you find any information that is out-dated, incorrect or incomplete, do not hesitate to Open a ticket.

1. Introduction

The GridUI (Grid User Interface) cluster is the interactive gateway to the Advanced Computing and e-Science resources at IFCA. This cluster is comprised of a pool of machines reachable through a single entry point. The connections to the internal machines are managed by a director node that tries to ensure that proper balancing is made across the available nodes at a given moment.

Please note that this cluster is not intended for the execution of CPU intensive tasks, for this purpose use any of the available computing resources. Every process spawned is limited to a maximum CPU time of 2 hours.

Login on these machines is provided via Secure Shell. Outgoing SSH connections are not allowed by default from this cluster. Inactive SSH sessions may be closed after 12h. It is highly recommended that you set up SSH Keys for authentication, instead of using your username and password.

  • Hostname

    Operating System

    SSH server key fingerprint

    gridui.ifca.es, griduisl6.ifca.es

    Scientific Linux 6.X

    29:80:9b:28:e7:8a:00:fe:6c:60:ef:e6:a6:71:33:bd

2. Authentication and user accounts

See Cluster/SSO.

3. Access to Scientific Linux 5 machines

After the [[https://grid.ifca.es/sl5-user-interfaces-deprecation-plan2.html|Scientific Linux 5 deprecation]] interactive access to Scientific Linux 5 is still possible trough the batch system. In order to request a SLC5 machine you must append the complex scientificlinux5 to your request:

user@cloudprv-10-0:~ $ qsub -l scientificlinux5=true (...)

If you want an interactive session, append the complex to your qlogin request:

user@cloudprv-10-0:~ $ qlogin -l scientificlinux5=true (...)
JSV "/nfs4/opt/gridengine/util/resources/jsv/jsv-IFCA.tcl" has been started
JSV "/nfs4/opt/gridengine/util/resources/jsv/jsv-IFCA.tcl" has been stopped
Your job 1822278 ("QLOGIN") has been submitted
waiting for interactive job to be scheduled ...
Your interactive job 1822278 has been successfully scheduled.
Establishing builtin session to host cloudprv-02-9.ifca.es ...
user@cloudprv-02-9:~$ cat /etc/redhat-release
Scientific Linux SL release 5.5 (Boron)
user@cloudprv-02-9:~$  

4. SGE Cluster

The SGE Cluster is based on Scientific Linux CERN SLC release 6.2 machines, running on x86_64.

Local submission is allowed for certain projects. As stated below, there are some shared areas that can be accessed from the computing nodes. The underlying batch system is Son of Grid Engine 8.0.0d. Refer to the following sources for information:

IFCA Gridengine documentation has moved

The specific documentation for IFCA has been moved to a separate section.

5. Shared areas

The $HOME directories are shared between the UIs and the computing nodes. There is a projects shared area (located at /gpfs/csic_projects/), also accessible from the UI and the computing nodes. If your group does not have this area, please open an Incidence ticket.

5.1. Usage

The shared directories are not intended for scratch, use the temporal areas of the local filesystems instead. In other words, instruct every job you send to copy the input from the shared directory to the local scratch ($TMPDIR), execute all operations there, then copy the output back to some shared area where you will be able to retrieve it comfortably from the UI.

As mentioned above, the contents of $TMPDIR are removed after job execution.

5.2. Disk quotas

Disk quotas are enabled on both user and projects filesystems. A message with this information should be shown upon login. If you need more quota on your user space (not in the project shared area), please contact the system administrators explaining your reasons.

If you wish to check your quota at a later time, you can use the commands mmlsquota gpfs_csic (for user quotas) and mmlsquota -g id -g gpfs_projects (for group quotas). A script reporting both quotas is located on /nfs4/usr/bin/rep-user-quotas.py. A sample output of the latter could be:

**********************************************************************
                    INFORMATION ABOUT YOUR CURRENT DISK USAGE

USER                Used      Soft      Hard     Doubt     Grace
Space (GB):         3.41     20.00      0.00      0.06      none
Files (x1000):        64         0         0         0      none

GROUP               Used      Soft      Hard     Doubt     Grace
Space (GB):         0.00   1000.00   1500.00      0.00      none
Files (x1000):         0         0         0         0      none
**********************************************************************

For a basic interpretation of this output, note that the "Used" column will tell you about how much disk space you are using, whereas "Soft" denotes the limit this "Used" amount should not exceed. The "Hard" column is the value of the limit "Used" plus "Doubt" should not cross. A healthy disk space management would require that you periodically delete unused files in your $HOME directory, keeping its usage below the limits at all times. In the event that the user exceeds a limit, a grace period will be shown in the "Grace" column. If the user does not correct the situation within the grace period, she will be banned from writing to the disk.

For further information you can read the mmlsquota command manual page.

6. Extra utils/Software

Some extra packages can be found at /nfs4/opt/. This is the location for some pieces of software commonly used like:

  • Matlab's like octave language for numerical analysis.

  • Data plotting gnuplot program.

  • Profiling and debugging valgrind tools.

Please note that these packages are provided as-is, without further support from IFCA staff.

7. Support

Before opening a new incidence, please check the Frequently Asked Questions page

Questions, support and/or feedback should be directed through the use the Helpdesk.


CategoryUserSupport

eciencia: Cluster/Usage (last edited 2017-02-17 08:58:31 by aloga)