Tuning file descriptor limits on Linux
Linux limits the number of file descriptors that any one process may open; the default limits are 1024 per process. These limits can prevent optimum performance of both benchmarking clients (such as httperf and apachebench) and of the web servers themselves (Apache is not affected, since it uses a process per connection, but single process web servers such as Zeus use a file descriptor per connection, and so can easily fall foul of the default limit).
The open file limit is one of the limits that can be tuned with the ulimit command. The command ulimit -aS displays the current limit, and ulimit -aH displays the hard limit (above which the limit cannot be increased without tuning kernel parameters in /proc).
The following is an example of the output of ulimit -aH. You can see that the current shell (and its children) is restricted to 1024 open file descriptors.
core file size (blocks) unlimited
data seg size (kbytes) unlimited
file size (blocks) unlimited
max locked memory (kbytes) unlimited
max memory size (kbytes) unlimited
open files 1024
pipe size (512 bytes) 8
stack size (kbytes) unlimited
cpu time (seconds) unlimited
max user processes 4094
virtual memory (kbytes) unlimited
Increasing the file descriptor limit
The file descriptor limit can be increased using the following procedure:
1. Edit /etc/security/limits.conf and add the lines:
* soft nofile 1024
* hard nofile 65535
2. Edit /etc/pam.d/login, adding the line:
session required /lib/security/pam_limits.so
3. The system file descriptor limit is set in /proc/sys/fs/file-max. The following command will increase the limit to 65535:
echo 65535 > /proc/sys/fs/file-max
4. You should then be able to increase the file descriptor limits using:
ulimit -n unlimited
The above command will set the limits to the hard limit specified in /etc/security/limits.conf.
or---
Increase the limit from 64 (default) to 2048 by issuing the command:
ulimit -n 2048
Also, some applications like the SCO JDK require that the virtual memory resource limit be set to unlimited.
ulimit -v unlimited
Note that you may need to log out and back in again before the changes take effect.
Monday, June 18, 2007
Thursday, June 7, 2007
Tuning PostgreSQL for performance
Tuning PostgreSQL for performance
Shridhar Daithankar, Josh Berkus
July 3, 2003 Copyright 2003 Shridhar Daithankar and Josh Berkus.
Authorized for re-distribution only under the PostgreSQL license (see www.postgresql.org/license).
Table of Contents
1 Introduction
2 Some basic parameters
2.1 Shared buffers
2.2 Sort memory
2.3 Effective Cache Size
2.4 Fsync and the WAL files
3 Some less known parameters
3.1 random_ page_cost
3.2 Vacuum_ mem
3.3 max_fsm_pages
3.4 max fsm_ relations
3.5 wal_buffers
4 Other tips
4.1 Check your file system
4.2 Try the Auto Vacuum daemon
4.3 Try FreeBSD
5 The CONF Setting Guide
1 Introduction
This is a quick start guide for tuning PostgreSQL's settings for performance. This assumes minimal familiarity with PostgreSQL administration. In particular, one should know,
* How to start and stop the postmaster service
* How to tune OS parameters
* How to test the changes
It also assumes that you have gone through the PostgreSQL administration manual before starting, and to have set up your PostgreSQL server with at least the default configuration.
There are two important things for any performance optimization:
* Decide what level of performance you want
If you don't know your expected level of performance, you will end up chasing a carrot always couple of meters ahead of you. The performance tuning measures give diminishing returns after a certain threshold. If you don't set this threshold beforehand, you will end up spending lot of time for minuscule gains.
* Know your load
This document focuses entirely tuning postgresql.conf best for your existing setup. This is not the end of performance tuning. After using this document to extract the maximum reasonable performance from your hardware, you should start optimizing your application for efficient data access, which is beyond the scope of this article.
Please also note that the tuning advices described here are hints. You should not implement them all blindly. Tune one parameter at a time and test its impact and decide whether or not you need more tuning. Testing and benchmarking is an integral part of database tuning.
Tuning the software settings explored in this article is only about one-third of database performance tuning, but it's a good start since you can experiment with some basic setting changes in an afternoon, whereas some other aspects of tuning can be very time-consuming. The other two-thirds of database application tuning are:
* Hardware Selection and Setup
Databases are very bound to your system's I/O (disk) access and memory usage. As such, selection and configuration of disks, RAID arrays, RAM, operating system, and competition for these resources will have a profound effect on how fast your database is. We hope to have a later article covering this topic.
* Efficient Application Design
Your application also needs to be designed to access data efficiently, though careful query writing, planned and tested indexing, good connection management, and avoiding performance pitfalls particular to your version of PostgreSQL. Expect another guide someday helping with this, but really it takes several large books and years of experience to get it right ... or just a lot of time on the mailing lists.
2 Some basic parameters
2.1 Shared buffers
Shared buffers defines a block of memory that PostgreSQL will use to hold requests that are awaiting attention from the kernel buffer and CPU. The default value is quite low for any real world workload and need to be beefed up. However, unlike databases like Oracle, more is not always better. There is a threshold above which increasing this value can hurt performance.
This is the area of memory PostgreSQL actually uses to perform work. It should be sufficient enough to handle load on database server. Otherwise PostgreSQL will start pushing data to file and it will hurt the performance overall. Hence this is the most important setting one needs to tune up.
This value should be set based on the dataset size which the database server is supposed to handle at peak loads and on your available RAM (keep in mind that RAM used by other applications on the server is not available). We recommend following rule of thumb for this parameter:
* Start at 4MB (512) for a workstation
* Medium size data set and 256-512MB available RAM: 16-32MB (2048-4096)
* Large dataset and lots of available RAM (1-4GB): 64-256MB (8192-32768)
PLEASE NOTE. PostgreSQL counts a lot on the OS to cache data files and hence does not bother with duplicating its file caching effort. The shared buffers parameter assumes that OS is going to cache a lot of files and hence it is generally very low compared with system RAM. Even for a dataset in excess of 20GB, a setting of 128MB may be too much, if you have only 1GB RAM and an aggressive-at-caching OS like Linux.
There is one way to decide what is best for you. Set a high value of this parameter and run the database for typical usage. Watch usage of shared memory using ipcs or similar tools. A recommended figure would be between 1.2 to 2 times peak shared memory usage.
2.2 Sort memory
This parameter sets maximum limit on memory that a database connection can use to perform sorts. If your queries have order-by or group-by clauses that require sorting large data set, increasing this parameter would help. But beware: this parameter is per sort, per connection. Think twice before setting this parameter too high on any database with many users. A recommended approach is to set this parameter per connection as and when required; that is, low for most simple queries and higher for large, complex queries and data dumps.
2.3 Effective Cache Size
This parameter allows PostgreSQL to make best possible use of RAM available on your server. It tells PostgreSQL the size of OS data cache. So that PostgreSQL can draw different execution plan based on that data.
Say there is 1.5GB RAM in your machine, shared buffers are set to 32MB and effective cache size is set to 800MB. So if a query needs 700MB of data set, PostgreSQL would estimate that all the data required should be available in memory and would opt for more aggressive plan in terms of optimization, involving heavier index usage and merge joins. But if effective cache is set to only 200MB, the query planner is liable to opt for the more I/O efficient sequential scan.
While setting this parameter size, leave room for other applications running on the server machine. The objective is to set this value at the highest amount of RAM which will be available to PostgreSQL all the time.
2.4 Fsync and the WAL files
This parameters sets whether or not write data to disk as soon as it is committed, which is done through Write Ahead Logging (WAL). If you trust your hardware, your power company, and your battery power supply enough, you set this to No for an immediate boost to data write speed. But be very aware that any unexpected database shutdown will force you to restore the database from your last backup.
If that's not an option for you, you can still have the protection of WAL and better performance. Simply move your WAL files, using either a mount or a symlink to the pg_xlog directory, to a separate disk or array from your main database files. In high-write-activity databases, WAL should have its own disk or array to ensure continuous high-speed access. Very large RAID arrays and SAN/NAS devices frequently handle this for you through their internal management systems.
3 Some less known parameters
3.1 random_page_cost
This parameter sets the cost to fetch a random tuple from the database, which influences the planner's choice of index vs. table scan. This is set to a high value as the default default based on the expectation of slow disk access. If you have reasonably fast disks like SCSI or RAID, you can lower the cost to 2. You need to experiment to find out what works best for your setup by running a variety of queries and comparing execution times.
3.2 Vacuum_mem
This parameter sets the memory allocated to Vacuum. Normally, vacuum is a disk intensive process, but raising this parameter will speed it up by allowing PostgreSQL to copy larger blocks into memory. Just don't set it so high it takes significant memory away from normal database operation. Things between 16-32MB should be good enough for most setups.
3.3 max_fsm_pages
PostgreSQL records free space in each of its data pages. This information is useful for vacuum to find out how many and which pages to look for when it frees up the space.
If you have a database that does lots of updates and deletes, that is going to generate dead tuples, due to PostgreSQL's MVCC system. The space occupied by dead tuples can be freed with vacuum, unless there is more wasted space than is covered by the Free Space Map, in which case the much less convenient "vacuum full" is required. By expanding the FSM to cover all of those dead tuples, you might never again need to run vacuum full except on holidays.
The best way to set max _ fsm _ pages is interactive; First, figure out the vacuum (regular) frequency of your database based on write activity; next, run the database under normal production load, and run "vacuum verbose analyze" instead of vacuum, saving the output to a file; finally, calculate the maximum total number of pages reclaimed between vacuums based on the output, and use that.
Remember, this is a database cluster wide setting. So bump it up enough to cover all databases in your database cluster. Also, each FSM page uses 6 bytes of RAM for administrative overhead, so increasing FSM substantially on systems low on RAM may be counter-productive.
3.4 max _ fsm _ relations
This setting dictates how many number of relations (tables) will be tracked in free space map. Again this is a database cluster-wide setting, so set it accordingly. In version 7.3.3 and later, this parameter should be set correctly as a default. In older versions, bump it up to 300-1000.
3.5 wal_buffers
This setting decides the number of buffers WAL(Write ahead Log) can have. If your database has many write transactions, setting this value bit higher than default could result better usage of disk space. Experiment and decide. A good start would be around 32-64 corresponding to 256-512K memory.
4 Other tips
4.1 Check your file system
On OS like Linux, which offers multiple file systems, one should be careful about choosing the right one from a performance point of view. There is no agreement between PostgreSQL users about which one is best.
Contrary to popular belief, today's journaling file systems are not necessarily slower compared to non-journaling ones. Ext2 can be faster on some setups but the recovery issues generally make its use prohibitive. Different people have reported widely different experiences with the speed of Ext3, ReiserFS, and XFS; quite possibly this kind of benchmark depends on a combination of file system, disk/array configuration, OS version, and database table size and distribution. As such, you may be better off sticking with the file system best supported by your distribution, such as ReiserFS for SuSE Linux or Ext3 for Red Hat Linux, not to forget XFS known for it's large file support . Of course, if you have time to run comprehensive benchmarks, we would be interested in seeing the results!
As an easy performance boost with no downside, make sure the file system on which your database is kept is mounted "noatime", which turns off the access time bookkeeping.
4.2 Try the Auto Vacuum daemon
There is a little known module in PostgreSQL contrib directory called as pgavd. It works in conjunction with statistics collector. It periodically connects to a database and checks if it has done enough operations since the last check. If yes, it will vacuum the database.
Essentially it will vacuum the database when it needs it. It would get rid of playing with cron settings for vacuum frequency. It should result in better database performance by eliminating overdue vacuum issues.
4.3 Try FreeBSD
Large updates, deletes, and vacuum in PostgreSQL are very disk intensive processes. In particular, since vacuum gobbles up IO bandwidth, the rest of the database activities could be affected adversely when vacuuming very large tables.
OS's from the BSD family, such as FreeBSD, dynamically alter the IO priority of a process. So if you lower the priority of a vacuum process, it should not chew as much bandwidth and will better allow the database to perform normally. Of course this means that vacuum could take longer, which would be problematic for a "vacuum full."
If you are not done with your choice of OS for your server platform, consider BSD for this reason.
5 The CONF Setting Guide
Available here is an Annotated Guide to the PostgreSQL configuration file settings, in both OpenOffice.org and PDF format. This guide expands on the official documentation and may eventually be incorporated into it.
* The first column of the chart is the GUC setting in the postgresql.conf file.
* The second is the maximum range of the variable; note that the maximum range is often much larger than the practical range. For example, random_page_cost will accept any number between 0 and several billion, but all practical numbers are between 1 and 5.
* The third column contains an enumeration of RAM or disk space used by each unit of the parameter.
* The fourth column indicates whether or not the variable may be SET from the PSQL terminal during an interactive setting. Most settings marked as "no" may only be changed by restarting PostgreSQL.
* The fifth column quotes the official documentation available from the PostgreSQL web site.
* The last column is our notes on the setting, how to set it, resources it uses, etc. You'll notice some blank spaces, and should be warned as well that there is still strong disagreement on the value of many settings.
Users of PostgreSQL 7.3 and earlier will notice that the order of the parameters in this guide do not match the order of the parameters in your postgresql.conf file. This is because this document was generated as part of an effort to re-organize the conf parameters and documentation; starting with 7.4, this document, the official documentation, and the postgresql.conf file are all in the same logical order.
As noted in the worksheet, it covers PostgreSQL versions 7.3 and 7.4. If you are using an earlier version, you will not have access to all of these settings, and defaults and effects of some settings will be different.
Shridhar Daithankar, Josh Berkus
July 3, 2003 Copyright 2003 Shridhar Daithankar and Josh Berkus.
Authorized for re-distribution only under the PostgreSQL license (see www.postgresql.org/license).
Table of Contents
1 Introduction
2 Some basic parameters
2.1 Shared buffers
2.2 Sort memory
2.3 Effective Cache Size
2.4 Fsync and the WAL files
3 Some less known parameters
3.1 random_ page_cost
3.2 Vacuum_ mem
3.3 max_fsm_pages
3.4 max fsm_ relations
3.5 wal_buffers
4 Other tips
4.1 Check your file system
4.2 Try the Auto Vacuum daemon
4.3 Try FreeBSD
5 The CONF Setting Guide
1 Introduction
This is a quick start guide for tuning PostgreSQL's settings for performance. This assumes minimal familiarity with PostgreSQL administration. In particular, one should know,
* How to start and stop the postmaster service
* How to tune OS parameters
* How to test the changes
It also assumes that you have gone through the PostgreSQL administration manual before starting, and to have set up your PostgreSQL server with at least the default configuration.
There are two important things for any performance optimization:
* Decide what level of performance you want
If you don't know your expected level of performance, you will end up chasing a carrot always couple of meters ahead of you. The performance tuning measures give diminishing returns after a certain threshold. If you don't set this threshold beforehand, you will end up spending lot of time for minuscule gains.
* Know your load
This document focuses entirely tuning postgresql.conf best for your existing setup. This is not the end of performance tuning. After using this document to extract the maximum reasonable performance from your hardware, you should start optimizing your application for efficient data access, which is beyond the scope of this article.
Please also note that the tuning advices described here are hints. You should not implement them all blindly. Tune one parameter at a time and test its impact and decide whether or not you need more tuning. Testing and benchmarking is an integral part of database tuning.
Tuning the software settings explored in this article is only about one-third of database performance tuning, but it's a good start since you can experiment with some basic setting changes in an afternoon, whereas some other aspects of tuning can be very time-consuming. The other two-thirds of database application tuning are:
* Hardware Selection and Setup
Databases are very bound to your system's I/O (disk) access and memory usage. As such, selection and configuration of disks, RAID arrays, RAM, operating system, and competition for these resources will have a profound effect on how fast your database is. We hope to have a later article covering this topic.
* Efficient Application Design
Your application also needs to be designed to access data efficiently, though careful query writing, planned and tested indexing, good connection management, and avoiding performance pitfalls particular to your version of PostgreSQL. Expect another guide someday helping with this, but really it takes several large books and years of experience to get it right ... or just a lot of time on the mailing lists.
2 Some basic parameters
2.1 Shared buffers
Shared buffers defines a block of memory that PostgreSQL will use to hold requests that are awaiting attention from the kernel buffer and CPU. The default value is quite low for any real world workload and need to be beefed up. However, unlike databases like Oracle, more is not always better. There is a threshold above which increasing this value can hurt performance.
This is the area of memory PostgreSQL actually uses to perform work. It should be sufficient enough to handle load on database server. Otherwise PostgreSQL will start pushing data to file and it will hurt the performance overall. Hence this is the most important setting one needs to tune up.
This value should be set based on the dataset size which the database server is supposed to handle at peak loads and on your available RAM (keep in mind that RAM used by other applications on the server is not available). We recommend following rule of thumb for this parameter:
* Start at 4MB (512) for a workstation
* Medium size data set and 256-512MB available RAM: 16-32MB (2048-4096)
* Large dataset and lots of available RAM (1-4GB): 64-256MB (8192-32768)
PLEASE NOTE. PostgreSQL counts a lot on the OS to cache data files and hence does not bother with duplicating its file caching effort. The shared buffers parameter assumes that OS is going to cache a lot of files and hence it is generally very low compared with system RAM. Even for a dataset in excess of 20GB, a setting of 128MB may be too much, if you have only 1GB RAM and an aggressive-at-caching OS like Linux.
There is one way to decide what is best for you. Set a high value of this parameter and run the database for typical usage. Watch usage of shared memory using ipcs or similar tools. A recommended figure would be between 1.2 to 2 times peak shared memory usage.
2.2 Sort memory
This parameter sets maximum limit on memory that a database connection can use to perform sorts. If your queries have order-by or group-by clauses that require sorting large data set, increasing this parameter would help. But beware: this parameter is per sort, per connection. Think twice before setting this parameter too high on any database with many users. A recommended approach is to set this parameter per connection as and when required; that is, low for most simple queries and higher for large, complex queries and data dumps.
2.3 Effective Cache Size
This parameter allows PostgreSQL to make best possible use of RAM available on your server. It tells PostgreSQL the size of OS data cache. So that PostgreSQL can draw different execution plan based on that data.
Say there is 1.5GB RAM in your machine, shared buffers are set to 32MB and effective cache size is set to 800MB. So if a query needs 700MB of data set, PostgreSQL would estimate that all the data required should be available in memory and would opt for more aggressive plan in terms of optimization, involving heavier index usage and merge joins. But if effective cache is set to only 200MB, the query planner is liable to opt for the more I/O efficient sequential scan.
While setting this parameter size, leave room for other applications running on the server machine. The objective is to set this value at the highest amount of RAM which will be available to PostgreSQL all the time.
2.4 Fsync and the WAL files
This parameters sets whether or not write data to disk as soon as it is committed, which is done through Write Ahead Logging (WAL). If you trust your hardware, your power company, and your battery power supply enough, you set this to No for an immediate boost to data write speed. But be very aware that any unexpected database shutdown will force you to restore the database from your last backup.
If that's not an option for you, you can still have the protection of WAL and better performance. Simply move your WAL files, using either a mount or a symlink to the pg_xlog directory, to a separate disk or array from your main database files. In high-write-activity databases, WAL should have its own disk or array to ensure continuous high-speed access. Very large RAID arrays and SAN/NAS devices frequently handle this for you through their internal management systems.
3 Some less known parameters
3.1 random_page_cost
This parameter sets the cost to fetch a random tuple from the database, which influences the planner's choice of index vs. table scan. This is set to a high value as the default default based on the expectation of slow disk access. If you have reasonably fast disks like SCSI or RAID, you can lower the cost to 2. You need to experiment to find out what works best for your setup by running a variety of queries and comparing execution times.
3.2 Vacuum_mem
This parameter sets the memory allocated to Vacuum. Normally, vacuum is a disk intensive process, but raising this parameter will speed it up by allowing PostgreSQL to copy larger blocks into memory. Just don't set it so high it takes significant memory away from normal database operation. Things between 16-32MB should be good enough for most setups.
3.3 max_fsm_pages
PostgreSQL records free space in each of its data pages. This information is useful for vacuum to find out how many and which pages to look for when it frees up the space.
If you have a database that does lots of updates and deletes, that is going to generate dead tuples, due to PostgreSQL's MVCC system. The space occupied by dead tuples can be freed with vacuum, unless there is more wasted space than is covered by the Free Space Map, in which case the much less convenient "vacuum full" is required. By expanding the FSM to cover all of those dead tuples, you might never again need to run vacuum full except on holidays.
The best way to set max _ fsm _ pages is interactive; First, figure out the vacuum (regular) frequency of your database based on write activity; next, run the database under normal production load, and run "vacuum verbose analyze" instead of vacuum, saving the output to a file; finally, calculate the maximum total number of pages reclaimed between vacuums based on the output, and use that.
Remember, this is a database cluster wide setting. So bump it up enough to cover all databases in your database cluster. Also, each FSM page uses 6 bytes of RAM for administrative overhead, so increasing FSM substantially on systems low on RAM may be counter-productive.
3.4 max _ fsm _ relations
This setting dictates how many number of relations (tables) will be tracked in free space map. Again this is a database cluster-wide setting, so set it accordingly. In version 7.3.3 and later, this parameter should be set correctly as a default. In older versions, bump it up to 300-1000.
3.5 wal_buffers
This setting decides the number of buffers WAL(Write ahead Log) can have. If your database has many write transactions, setting this value bit higher than default could result better usage of disk space. Experiment and decide. A good start would be around 32-64 corresponding to 256-512K memory.
4 Other tips
4.1 Check your file system
On OS like Linux, which offers multiple file systems, one should be careful about choosing the right one from a performance point of view. There is no agreement between PostgreSQL users about which one is best.
Contrary to popular belief, today's journaling file systems are not necessarily slower compared to non-journaling ones. Ext2 can be faster on some setups but the recovery issues generally make its use prohibitive. Different people have reported widely different experiences with the speed of Ext3, ReiserFS, and XFS; quite possibly this kind of benchmark depends on a combination of file system, disk/array configuration, OS version, and database table size and distribution. As such, you may be better off sticking with the file system best supported by your distribution, such as ReiserFS for SuSE Linux or Ext3 for Red Hat Linux, not to forget XFS known for it's large file support . Of course, if you have time to run comprehensive benchmarks, we would be interested in seeing the results!
As an easy performance boost with no downside, make sure the file system on which your database is kept is mounted "noatime", which turns off the access time bookkeeping.
4.2 Try the Auto Vacuum daemon
There is a little known module in PostgreSQL contrib directory called as pgavd. It works in conjunction with statistics collector. It periodically connects to a database and checks if it has done enough operations since the last check. If yes, it will vacuum the database.
Essentially it will vacuum the database when it needs it. It would get rid of playing with cron settings for vacuum frequency. It should result in better database performance by eliminating overdue vacuum issues.
4.3 Try FreeBSD
Large updates, deletes, and vacuum in PostgreSQL are very disk intensive processes. In particular, since vacuum gobbles up IO bandwidth, the rest of the database activities could be affected adversely when vacuuming very large tables.
OS's from the BSD family, such as FreeBSD, dynamically alter the IO priority of a process. So if you lower the priority of a vacuum process, it should not chew as much bandwidth and will better allow the database to perform normally. Of course this means that vacuum could take longer, which would be problematic for a "vacuum full."
If you are not done with your choice of OS for your server platform, consider BSD for this reason.
5 The CONF Setting Guide
Available here is an Annotated Guide to the PostgreSQL configuration file settings, in both OpenOffice.org and PDF format. This guide expands on the official documentation and may eventually be incorporated into it.
* The first column of the chart is the GUC setting in the postgresql.conf file.
* The second is the maximum range of the variable; note that the maximum range is often much larger than the practical range. For example, random_page_cost will accept any number between 0 and several billion, but all practical numbers are between 1 and 5.
* The third column contains an enumeration of RAM or disk space used by each unit of the parameter.
* The fourth column indicates whether or not the variable may be SET from the PSQL terminal during an interactive setting. Most settings marked as "no" may only be changed by restarting PostgreSQL.
* The fifth column quotes the official documentation available from the PostgreSQL web site.
* The last column is our notes on the setting, how to set it, resources it uses, etc. You'll notice some blank spaces, and should be warned as well that there is still strong disagreement on the value of many settings.
Users of PostgreSQL 7.3 and earlier will notice that the order of the parameters in this guide do not match the order of the parameters in your postgresql.conf file. This is because this document was generated as part of an effort to re-organize the conf parameters and documentation; starting with 7.4, this document, the official documentation, and the postgresql.conf file are all in the same logical order.
As noted in the worksheet, it covers PostgreSQL versions 7.3 and 7.4. If you are using an earlier version, you will not have access to all of these settings, and defaults and effects of some settings will be different.
Tuesday, June 5, 2007
iax2 one-way audio
After a while of operation, IAX becomes behaving incorrectly, no audio or 1-way, and no-answer :
This problem happened on asterisk 2.1.14.
The solution is configure the
jitterbuffer=no
This problem happened on asterisk 2.1.14.
The solution is configure the
jitterbuffer=no
Thursday, May 31, 2007
GWT-app does not first show when loading (IE 6)
Modules can contain references to external JavaScript and CSS files, causing them to be automatically loaded when the module itself is loaded.
But when injection of CSS file make the IE does not show the GWT widgits until you click on the page manually.
To work around this, donot use css injection but using normal way of embed the css file in html template
But when injection of CSS file make the IE does not show the GWT widgits until you click on the page manually.
To work around this, donot use css injection but using normal way of embed the css file in html template
Monday, May 28, 2007
jboss ejb3 and eager loading
In case of using annotation @OneToMany(mappedBy="order",cascade=CascadeType.ALL, fetch=FetchType.EAGER), the ear deployment broken.
To work around this problem, remove the fetch=FetchType.EAGER
or
Use either: Set or List with an explicit @IndexColumn, rather than a bag semantic collection like Collection.
@IndexColumn is an hibernate annotation
To work around this problem, remove the fetch=FetchType.EAGER
or
Use either: Set or List with an explicit @IndexColumn, rather than a bag semantic collection like Collection.
@IndexColumn is an hibernate annotation
Friday, May 18, 2007
Solaris x86
Hardware:
To setup the server testing enviroment, Sun utral 20 box is used. This box has two harddisks: (1)/dev/dsk/c1d0 and (2)/dev/dsk/c2d0
During installation of the Solaris 10, the first harddisk is used to install the boot, swap and root partitions. Basically, which likes the normal linux setting up.
The second harddisk /dev/dsk/c2d0 is left for the "zpool", although zpool can also use the extra space in the first disk.
After OS installation, the system status is : Solaris OS is installed in the first hardisk (/dev/dsk/c1d0). And the second harddisk is totally not used.
--------------------------After the installation of OS-------------------------
(1)create resource pool by command zpool
#zpool create spool c2d0
(2)now the pool named "spool" is created. Which can be listed by:
#zpool list
(3)Creating a ZFS File System by allocating space from the pool "spool"
#zfs create spool/z1fs
(4)now, new ZFS file system is created, which can be listed by:
#zfs list
(5)Now, it is time to create the parent directory of all zones: In the following, /zones directory is created.
#mkdir /zones
(6)To create zone "z1", i create directory /zones/z1,
#mkdir /zones/z1
(7)and mount the newly create ZFS spool/z1fs to /zone/z1
#zfs set mountpoint=/zones/z1 spool/z1fs
(8)and set the quato for ZFS spool/z1fs
#zfs set quota=10G spool/z1fs
(9) It is time to create zone z1 now:
#zonecfg -z z1
z1: No such zone configured
Use 'create' to begin configuring a new zone
zonecfg:myzone< create
zonecfg:myzone< set zonepath=/zones/z1
zonecfg:myzone< verify
zonecfg:myzone< commit
zonecfg:myzone< exit
(10)Install the zone by using the zoneadm
#chmod 700 /zones/z1
#zoneadm -z z1 install
(11)Boot the zone to complete the installation, using the zoneadm command.
# zoneadm -z z1 boot
(12)Use the zlogin command to connect to the zone console and answer the initialization questions:
#zlogin -C z1
(13)to shutdown zone
#zlogin z1 init 5
----------------------------------------------------
Configure network for the zone
Context: the Sun utral 20 box has only one physical network interface. To make the zone created network accessable, one logical interface will be assigned to each zone.
(1)list the physical network interface on Sun utral 20 box:
#ifconfig -a
The result shows that the physical network interface is nge0
(2)create logical interface and assign it to zone z1 and then up the logical interface:
#ifconfig nge0:1 plumb 192.168.1.89 netmask 255.255.255.0 zone z1 up
(3)login into z1:
#zlogin z1
(4)modify /etc/ssh/sshd_config , so that "root" can be used to do remote login
(5)restart sshd:
#svcadm restart ssh
------------------------------------------------------------------
DNS clients configuration:
After zone is running, it could encount such a problem: When you do ping to other computer, the naming resolving does not work. This is due to the DNS client configuration is not correct.
All DNS clients require the presence of the /etc/nsswitch.conf and /etc/resolv.conf files. Note that the DNS server must also be configured as a DNS client if it intends to use its own DNS services.
The /etc/nsswitch.conf file specifies the resolver library routines to be used for resolving host names and addresses. Modify the /etc/nsswitch.conf file by editing the hosts entry and adding the dns keyword. To ensure proper network interface configuration during the boot process, make sure that the files keyword is listed first. The following example shows a hosts entry configured for DNS:
hosts: files dns
The /etc/resolv.conf file specifies the name servers that the client must use, the client's domain name, and the search path to use for queries.
; resolv.conf file for DNS clients of the one.edu domain
domain office1.abc.net
nameserver 192.168.1.119
search office1.abc.net
Observe that the search keyword specifies domain names to append to queries that were not specified in the FQDN format. The first domain listed following the search keyword designates the client's domain. If both "domain" and "search" keywords are present, then the last one in the file is used and the other one(s) are ignored.
The nameserver keyword specifies the IP address of the DNS servers to query. Do not specify host names. You can use up to three nameserver keywords to increase your chances of finding a responsive server. In general, list the name servers that are nearer to the local network first. The client attempts to use the loopback address if there is no nameserver keyword or if the /etc/resolv.conf file does not exists.
------------------------------------------------------------------------
Configure DHCP client
After crashing of sun ultra 20 box, a dell box with onboard networking card is used to install solaris.
Problem 1: solaris doesn't support this on-board networking card.
Solution: a standalone PCI network card is used.
Problem 2: Solaris cannot detect this PCI card, and what is the interface name of this card?
Solution: Google suggest to try names like le0, iprb0, elxl0 and rtls0 etc.
Problem3: how to configure the DHCP client?
Solution: for a network interface, to configure it DHCP, create two empty files under /etc directory:
(a)hostname.INTERFACENAME , (b)dhcp.INTERFACENAME
After trying google suggested interface names, it is found that elxl0 is correct for this card.
--------------------------------------------------------------------------
Configure static IP addresses for the solaris box:
Network Interface Cards are what allow your system to talk to the network. When they don't work, neither do you. I will cover how to configure, troubleshoot, and modify your interfaces. I will not be covering routing issues, that will follow in the next article. My goal here is to get your interface up and properly running.
The first place to start is installing and testing the hardware. Once you have installed the hardware, SPARC systems can be tested at the EPROM level to verify the network interface cards. Use the manual that accompanies the interface card on how to test that specific card. Solaris x86 is a little different, as there is no true EPROM, and the drivers are different. However, Solaris x86 2.6 is Plug and Play compatible, and I have had fairly good luck adding network interface cards.
Once you have confirmed at the hardware and driver level that everything works, the fun can begin. The place to start is the ifconfig command. This powerful command allows you configure and modify your interfaces in real time. However, any modifications made with ifconfig are not permanent. When the system reboots, it will default to its previous configuration. I will first show you how to make all modifications with the ifconfig command. The second half of this article will cover making these modifications permanent by modifying the proper configuration files.
ifconfig
ifconfig -a
will show you which interfaces are currently installed and active. Remember, just because you added the physical network interface card does NOT mean it is active. If you do an ifconfig before you have configured the device, the interface will not show up. Once configured however, the typical output of the ifconfig -a command would look like this:
lo0: flags=849 mtu 8232
inet 127.0.0.1 netmask ff000000
elxl0: flags=863 mtu 1500
inet 192.168.1.132 netmask ffffff00 broadcast 192.168.1.255
ether 8:0:20:9c:6b:2d
Here we see two interfaces, lo0 and elxl0. lo0 is the standard loopback interface found on all systems. elxl0 is a 10/100 Mbps interface. All hme interfaces are 10/100 Mbps, all le interfaces are 10 Mbps, all qe interface are quad 10 Mbps, and qfe interfaces are quad 10/100 Mbps. There are three lines of information about the interface. The first line is about the TCP/IP stack. For the interface elxl0, we see the system is up, running both broadcast and multicast, with a mtu (maximum transfer unit) of 1500 bytes, standard for an Ethernet LAN. Notrailers is a flag no longer used, but kept for backwards compatibility reasons.
The second line is about the IP addressing. Here we see the IP address, netmask in hexadecimal format, and the broadcast address. The third line is the MAC address. Unlike most interfaces, Sun Microsystems's interfaces derive the MAC addressing from the NVRAM, not the interface itself. Thus, all the interfaces on a single SPARC system will have the same MAC address. This does not cause a problem in routing, since most NICs are always on a different network. Note, you must be root to see the MAC address with the ifconfig command, any other user will only see the first two lines of information.
The first step in bringing up an interface is "plumbing" the interface. By plumbing, we are implementing the TCP/IP stack. We will use the above interface, elxl0, as an example. Lets say we had just physically added this network interface card and rebooted, now what? First, we plumb the device with the plumb command.
ifconfig elxl0 plumb
This sets up the streams needed for TCP/IP to use the device. However, the stack has not been configured as you can see below.
elxl0: flags=842 mtu 1500
inet 0.0.0.0 netmask 0
ether 8:0:20:9c:6b:2d
The next step is to configure the TCP/IP stack. We configure the stack by adding the IP address, netmask, and then telling the device it is up. All this can be down in one command, as seen below.
ifconfig elxl0 192.168.1.132 netmask 255.255.255.0 up
This single command configures the entire device. Notice the up command, which initializes the interface. The interface can be in one of two states, up or down. When an interface is down, the system does not attempt to transmit messages through that interface. A down interface will still show with the ifconfig command, however it will not have the word "up" on the first line.
Virtual interfaces
Before moving on to the configuration files, I would first like to cover virtual interfaces. A virtual interface is one or more logical interfaces assigned to an already existing interface. Solaris can have up to 255 virtual interfaces assigned to a single interface.
Once again, lets take the interface elxl0 as an example. We have already covered how to configure this device. However, lets say the device is on a VLAN (virtual LAN) with several networks sharing the same wire. We can configure the device elxl0 to answer to another IP address, say 172.20.15.4. To do so, the command would be the same as used for elxl0, except the virtual interface is called elxl0:*, where * is the number you assign to the virtual interface. For example, virtual interface one would be elxl0:1. The command to configure it looks as follows.
ifconfig elxl0:1 172.20.15.4 netmask 255.255.0.0 up
Once you have configured the virtual interface, you can compare elxl0 and elxl0:1 with the ifconfig command.
elxl0: flags=843 mtu 1500
inet 192.168.1.132 netmask ffffff00 broadcast 192.168.1.255
ether 8:0:20:9c:6b:2d
elxl0:1: flags=842 mtu 1500
inet 172.20.15.4 netmask ffff0000 broadcast 172.20.255.255
Here you see the two devices, both of which are on the same physical device. Notice how the virtual interface elxl0:1 has no MAC address, as this is the same device as elxl0. We can repeat this process all the way up to elxl0:255. The operating system and most applications will treat these virtual devices as totally independent devices.
Note, Matthew A. Domurat has identified a "bug" with Solaris 2.6. When working with virtual interfaces, Solaris 2.6 will randomly select one of the interfaces as its source address for every packet sent. These are the patches to fix this:
* 105786-05: SunOS 5.6: /kernel/drv/ip patch
* 105787-04: SunOS 5.6_x86: /kernel/drv/ip patch
Configuration files
Now you know how to configure your network interface cards. Unfortunately, any modifications, additions, or deletions you make with ifconfig are only temporary, you will lose these configurations when you reboot. I will now discuss what files you have to configure to make these changes permanent.
The place to start is the file /etc/hostname.*, where * is the name of the interface. In the case of elxl0, the file name is /etc/hostname.elxl0. The virtual interface elxl0:1 would have the file name /etc/hostname.elxl0:1. This file has a single entry, the name of the interface. This name is used in the /etc/hosts file to resolve name to IP address.
The file /etc/hostname.* is critical, this is what causes the device to be plumbed. During the boot process, the /etc/rcS.d/S30network.sh file reads all the /etc/hostname.* files and plumbs the devices. Once plumbed, the devices are configured by reading the /etc/hosts and the /etc/netmasks file. By reading these two files, the device is configured for the proper IP and netmask, and brought to an up state. Lets take the device elxl0 as an example. During the boot process, /etc/rcS.d/S30network.sh looks for any /etc/hostname.* files. It finds /etc/hostname.elxl0, which contains the following entry.
homer
/etc/rcS.d/S30network.sh looks in /etc/hosts and resolves the name homer with an IP address of 192.168.1.132. The device elxl0 is now assigned this IP address. The script then looks at /etc/netmasks to find the netmask for that IP address. With this information, the startup script brings up interface elxl0 with an IP address of 192.168.1.132 and a netmask of 255.255.255.0. It may seem redundant having the script review the netmask of a class C address. However, do not forget that, starting with 2.6, Solaris supports both classless routing and VLSM (Variable Length Subnet Masks), both of which I will discuss in my next article.
As you have seen in this example, there are three files that must be modified for every interface. The first is /etc/hostname.*, this is the file you create to designate the interface's name. The second file is /etc/hosts, here you resolve the IP to the interface name. Last is /etc/netmasks, this is where you define the netmask of the IP address.
--------------------------------------------------------------
Install Solaris OS and partition on Dell Box
The Dell Box has one IDE harddisk with about 120G capacity. Solaris identifies this disk to be c0d0.
During installation, fdisk partition it as
c0d0s0 which mount on /
c0d0s1 ----swap
c0d0s7 ----/export/home
c0d0s3,4,5,6 all not used but with 20G space. they will be used as the resources of the resource pool created by zpool.
----------------------------------------------------
create harddisk resource pool
(1)#zpool create spool c0d0s3
(2)#zpool add spool c0d0s4
(4)#zpool list
NAME SIZE USED AVAIL CAP HEALTH ALTROOT
spool 39G 196K 39.0G 0% ONLINE
-----------------------------------------------------------
set static IP for global zone:
refer to the doc on above comments....
To set static IP for global zone:
(1)create /etc/hosts file. so that:
#less hosts
#
# Internet host table
#
192.168.1.23 benchmark1
(2)create /etc/hostname.elxl0 so that:
#less hostname.elxl0
benchmark1
After these two files created, global zone are network enabled.
-----------------------------------------------------------------
setup static ip for zone benchmark2 (non-global zone)
After login into global zone,
if doing #ifconfig -a,
lo0: flags=2001000849 mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
elxl0: flags=1000843 mtu 1500 index 2
inet 192.168.1.23 netmask ffffff00 broadcast 192.168.1.255
ether 0:1:2:12:67:53
#zonecfg -z benchmark2
=>add net
==>set ip=192.168.1.23
==>set physical=elxl0
...
and commit
After boot zone benchmark2, Now, do #ifconfig -a again:
lo0: flags=2001000849 mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
lo0:1: flags=2001000849 mtu 8232 index 1
zone benchmark2
inet 127.0.0.1 netmask ff000000
elxl0: flags=1000843 mtu 1500 index 2
inet 192.168.1.23 netmask ffffff00 broadcast 192.168.1.255
ether 0:1:2:12:67:53
elxl0:1: flags=1000843 mtu 1500 index 2
zone benchmark2
inet 192.168.1.22 netmask ffffff00 broadcast 192.168.1.255
It indicates that non-global zone is already network enabled.
-----------------------------------------------
JBOSS setup
Copy jboss from zpeter4:
Including:
(1)/opt/jboss-4.0.4.GA
(2)/var/jboss
(3)/opt/bin/myip (this is used in jboss's run.sh file)
(4)if java security manager is included in the java parameter, make sure the corresponding policy file also there
---------------------------------------------------
JBOSS user
(1)user jboss must be created
(2)group jboss must be created
(3)home directory of user jboss must be /var/jboss
[ Show » ]
Peter Yang [16/May/07 12:27 PM] JBOSS user (1)user jboss must be created (2)group jboss must be created (3)home directory of user jboss must be /var/jboss
----------------------------------------------------------
Setup SMF for jboss:
(1)export smf script from zpeter4
#svccfg export jboss >/tmp/jboss.xml
and copy this exported file to new zone benchmark2.
(2)Copy /opt/lib/svc/method/svc-jboss from zpeter4 to benchmark2 zone in the corresponding directory
(3)import manifect file jboss.xml in benchmark2 zone.
/usr/sbin/svccfg -v import /tmp/jboss.xml
(4)enable jboss
#svcadm enable jboss
(5)monitoring the status of jboss service
#svcs -xv jboss
------------------------------------------------
how to remove service or edit manifest file
svcadm -v disable svc:/network/jboss
svccfg -v delete svc:/network/jboss
svccfg -v import /var/svc/manifest/jboss.xml
----------------------------------------------------
How to run NFS file server and mount NFS client
Problem:
For the development enviroment, there are four JBOSS servers. To enable the web log feature of the portal, it is required for all these JBOSS server to send their log files to a central NFS server, on which jbossportal server is running.
Parameters:
(1)JBOSS servers:
zpeter2, zpeter3, zpeter4 and benchmark2 (dell computer)
(2)NFS file server is running on storm, on which zroland3 zone is running. JBossPortal is running with zroland3 zone.
Steps:
(1)edit /etc/dfs/dfstab on storm to include following lines:
share -F nfs -o rw -d "zpeter2:/var/jboss/log" /zones/zroland3/root/nfsd/zpeter2
share -F nfs -o rw -d "zpeter3:/var/jboss/log" /zones/zroland3/root/nfsd/zpeter3
share -F nfs -o rw -d "zpeter4:/var/jboss/log" /zones/zroland3/root/nfsd/zpeter4
share -F nfs -o rw -d "benchmark2:/var/jboss/log" /zones/zroland3/root/nfsd/benchmark2
(2)make sure the mode of /zones/zroland3/root/nfsd/zpeter2, /zones/zroland3/root/nfsd/zpeter3, /zones/zroland3/root/nfsd/zpeter3 and /zones/zroland3/root/nfs/benchmark2 are 777. So that files can be written in these directories.
(3)restart NFS server
(4)on zone zpeter2, edit /etc/vfstab to include line:
storm:/zones/zroland3/root/nfsd/zpeter2 - /log nfs - yes rw
and do the same thing for zones zpeter3, zpeter4 and benchmark2
(5)restart these zones
To setup the server testing enviroment, Sun utral 20 box is used. This box has two harddisks: (1)/dev/dsk/c1d0 and (2)/dev/dsk/c2d0
During installation of the Solaris 10, the first harddisk is used to install the boot, swap and root partitions. Basically, which likes the normal linux setting up.
The second harddisk /dev/dsk/c2d0 is left for the "zpool", although zpool can also use the extra space in the first disk.
After OS installation, the system status is : Solaris OS is installed in the first hardisk (/dev/dsk/c1d0). And the second harddisk is totally not used.
--------------------------After the installation of OS-------------------------
(1)create resource pool by command zpool
#zpool create spool c2d0
(2)now the pool named "spool" is created. Which can be listed by:
#zpool list
(3)Creating a ZFS File System by allocating space from the pool "spool"
#zfs create spool/z1fs
(4)now, new ZFS file system is created, which can be listed by:
#zfs list
(5)Now, it is time to create the parent directory of all zones: In the following, /zones directory is created.
#mkdir /zones
(6)To create zone "z1", i create directory /zones/z1,
#mkdir /zones/z1
(7)and mount the newly create ZFS spool/z1fs to /zone/z1
#zfs set mountpoint=/zones/z1 spool/z1fs
(8)and set the quato for ZFS spool/z1fs
#zfs set quota=10G spool/z1fs
(9) It is time to create zone z1 now:
#zonecfg -z z1
z1: No such zone configured
Use 'create' to begin configuring a new zone
zonecfg:myzone< create
zonecfg:myzone< set zonepath=/zones/z1
zonecfg:myzone< verify
zonecfg:myzone< commit
zonecfg:myzone< exit
(10)Install the zone by using the zoneadm
#chmod 700 /zones/z1
#zoneadm -z z1 install
(11)Boot the zone to complete the installation, using the zoneadm command.
# zoneadm -z z1 boot
(12)Use the zlogin command to connect to the zone console and answer the initialization questions:
#zlogin -C z1
(13)to shutdown zone
#zlogin z1 init 5
----------------------------------------------------
Configure network for the zone
Context: the Sun utral 20 box has only one physical network interface. To make the zone created network accessable, one logical interface will be assigned to each zone.
(1)list the physical network interface on Sun utral 20 box:
#ifconfig -a
The result shows that the physical network interface is nge0
(2)create logical interface and assign it to zone z1 and then up the logical interface:
#ifconfig nge0:1 plumb 192.168.1.89 netmask 255.255.255.0 zone z1 up
(3)login into z1:
#zlogin z1
(4)modify /etc/ssh/sshd_config , so that "root" can be used to do remote login
(5)restart sshd:
#svcadm restart ssh
------------------------------------------------------------------
DNS clients configuration:
After zone is running, it could encount such a problem: When you do ping to other computer, the naming resolving does not work. This is due to the DNS client configuration is not correct.
All DNS clients require the presence of the /etc/nsswitch.conf and /etc/resolv.conf files. Note that the DNS server must also be configured as a DNS client if it intends to use its own DNS services.
The /etc/nsswitch.conf file specifies the resolver library routines to be used for resolving host names and addresses. Modify the /etc/nsswitch.conf file by editing the hosts entry and adding the dns keyword. To ensure proper network interface configuration during the boot process, make sure that the files keyword is listed first. The following example shows a hosts entry configured for DNS:
hosts: files dns
The /etc/resolv.conf file specifies the name servers that the client must use, the client's domain name, and the search path to use for queries.
; resolv.conf file for DNS clients of the one.edu domain
domain office1.abc.net
nameserver 192.168.1.119
search office1.abc.net
Observe that the search keyword specifies domain names to append to queries that were not specified in the FQDN format. The first domain listed following the search keyword designates the client's domain. If both "domain" and "search" keywords are present, then the last one in the file is used and the other one(s) are ignored.
The nameserver keyword specifies the IP address of the DNS servers to query. Do not specify host names. You can use up to three nameserver keywords to increase your chances of finding a responsive server. In general, list the name servers that are nearer to the local network first. The client attempts to use the loopback address if there is no nameserver keyword or if the /etc/resolv.conf file does not exists.
------------------------------------------------------------------------
Configure DHCP client
After crashing of sun ultra 20 box, a dell box with onboard networking card is used to install solaris.
Problem 1: solaris doesn't support this on-board networking card.
Solution: a standalone PCI network card is used.
Problem 2: Solaris cannot detect this PCI card, and what is the interface name of this card?
Solution: Google suggest to try names like le0, iprb0, elxl0 and rtls0 etc.
Problem3: how to configure the DHCP client?
Solution: for a network interface, to configure it DHCP, create two empty files under /etc directory:
(a)hostname.INTERFACENAME , (b)dhcp.INTERFACENAME
After trying google suggested interface names, it is found that elxl0 is correct for this card.
--------------------------------------------------------------------------
Configure static IP addresses for the solaris box:
Network Interface Cards are what allow your system to talk to the network. When they don't work, neither do you. I will cover how to configure, troubleshoot, and modify your interfaces. I will not be covering routing issues, that will follow in the next article. My goal here is to get your interface up and properly running.
The first place to start is installing and testing the hardware. Once you have installed the hardware, SPARC systems can be tested at the EPROM level to verify the network interface cards. Use the manual that accompanies the interface card on how to test that specific card. Solaris x86 is a little different, as there is no true EPROM, and the drivers are different. However, Solaris x86 2.6 is Plug and Play compatible, and I have had fairly good luck adding network interface cards.
Once you have confirmed at the hardware and driver level that everything works, the fun can begin. The place to start is the ifconfig command. This powerful command allows you configure and modify your interfaces in real time. However, any modifications made with ifconfig are not permanent. When the system reboots, it will default to its previous configuration. I will first show you how to make all modifications with the ifconfig command. The second half of this article will cover making these modifications permanent by modifying the proper configuration files.
ifconfig
ifconfig -a
will show you which interfaces are currently installed and active. Remember, just because you added the physical network interface card does NOT mean it is active. If you do an ifconfig before you have configured the device, the interface will not show up. Once configured however, the typical output of the ifconfig -a command would look like this:
lo0: flags=849
inet 127.0.0.1 netmask ff000000
elxl0: flags=863
inet 192.168.1.132 netmask ffffff00 broadcast 192.168.1.255
ether 8:0:20:9c:6b:2d
Here we see two interfaces, lo0 and elxl0. lo0 is the standard loopback interface found on all systems. elxl0 is a 10/100 Mbps interface. All hme interfaces are 10/100 Mbps, all le interfaces are 10 Mbps, all qe interface are quad 10 Mbps, and qfe interfaces are quad 10/100 Mbps. There are three lines of information about the interface. The first line is about the TCP/IP stack. For the interface elxl0, we see the system is up, running both broadcast and multicast, with a mtu (maximum transfer unit) of 1500 bytes, standard for an Ethernet LAN. Notrailers is a flag no longer used, but kept for backwards compatibility reasons.
The second line is about the IP addressing. Here we see the IP address, netmask in hexadecimal format, and the broadcast address. The third line is the MAC address. Unlike most interfaces, Sun Microsystems's interfaces derive the MAC addressing from the NVRAM, not the interface itself. Thus, all the interfaces on a single SPARC system will have the same MAC address. This does not cause a problem in routing, since most NICs are always on a different network. Note, you must be root to see the MAC address with the ifconfig command, any other user will only see the first two lines of information.
The first step in bringing up an interface is "plumbing" the interface. By plumbing, we are implementing the TCP/IP stack. We will use the above interface, elxl0, as an example. Lets say we had just physically added this network interface card and rebooted, now what? First, we plumb the device with the plumb command.
ifconfig elxl0 plumb
This sets up the streams needed for TCP/IP to use the device. However, the stack has not been configured as you can see below.
elxl0: flags=842
inet 0.0.0.0 netmask 0
ether 8:0:20:9c:6b:2d
The next step is to configure the TCP/IP stack. We configure the stack by adding the IP address, netmask, and then telling the device it is up. All this can be down in one command, as seen below.
ifconfig elxl0 192.168.1.132 netmask 255.255.255.0 up
This single command configures the entire device. Notice the up command, which initializes the interface. The interface can be in one of two states, up or down. When an interface is down, the system does not attempt to transmit messages through that interface. A down interface will still show with the ifconfig command, however it will not have the word "up" on the first line.
Virtual interfaces
Before moving on to the configuration files, I would first like to cover virtual interfaces. A virtual interface is one or more logical interfaces assigned to an already existing interface. Solaris can have up to 255 virtual interfaces assigned to a single interface.
Once again, lets take the interface elxl0 as an example. We have already covered how to configure this device. However, lets say the device is on a VLAN (virtual LAN) with several networks sharing the same wire. We can configure the device elxl0 to answer to another IP address, say 172.20.15.4. To do so, the command would be the same as used for elxl0, except the virtual interface is called elxl0:*, where * is the number you assign to the virtual interface. For example, virtual interface one would be elxl0:1. The command to configure it looks as follows.
ifconfig elxl0:1 172.20.15.4 netmask 255.255.0.0 up
Once you have configured the virtual interface, you can compare elxl0 and elxl0:1 with the ifconfig command.
elxl0: flags=843
inet 192.168.1.132 netmask ffffff00 broadcast 192.168.1.255
ether 8:0:20:9c:6b:2d
elxl0:1: flags=842
inet 172.20.15.4 netmask ffff0000 broadcast 172.20.255.255
Here you see the two devices, both of which are on the same physical device. Notice how the virtual interface elxl0:1 has no MAC address, as this is the same device as elxl0. We can repeat this process all the way up to elxl0:255. The operating system and most applications will treat these virtual devices as totally independent devices.
Note, Matthew A. Domurat has identified a "bug" with Solaris 2.6. When working with virtual interfaces, Solaris 2.6 will randomly select one of the interfaces as its source address for every packet sent. These are the patches to fix this:
* 105786-05: SunOS 5.6: /kernel/drv/ip patch
* 105787-04: SunOS 5.6_x86: /kernel/drv/ip patch
Configuration files
Now you know how to configure your network interface cards. Unfortunately, any modifications, additions, or deletions you make with ifconfig are only temporary, you will lose these configurations when you reboot. I will now discuss what files you have to configure to make these changes permanent.
The place to start is the file /etc/hostname.*, where * is the name of the interface. In the case of elxl0, the file name is /etc/hostname.elxl0. The virtual interface elxl0:1 would have the file name /etc/hostname.elxl0:1. This file has a single entry, the name of the interface. This name is used in the /etc/hosts file to resolve name to IP address.
The file /etc/hostname.* is critical, this is what causes the device to be plumbed. During the boot process, the /etc/rcS.d/S30network.sh file reads all the /etc/hostname.* files and plumbs the devices. Once plumbed, the devices are configured by reading the /etc/hosts and the /etc/netmasks file. By reading these two files, the device is configured for the proper IP and netmask, and brought to an up state. Lets take the device elxl0 as an example. During the boot process, /etc/rcS.d/S30network.sh looks for any /etc/hostname.* files. It finds /etc/hostname.elxl0, which contains the following entry.
homer
/etc/rcS.d/S30network.sh looks in /etc/hosts and resolves the name homer with an IP address of 192.168.1.132. The device elxl0 is now assigned this IP address. The script then looks at /etc/netmasks to find the netmask for that IP address. With this information, the startup script brings up interface elxl0 with an IP address of 192.168.1.132 and a netmask of 255.255.255.0. It may seem redundant having the script review the netmask of a class C address. However, do not forget that, starting with 2.6, Solaris supports both classless routing and VLSM (Variable Length Subnet Masks), both of which I will discuss in my next article.
As you have seen in this example, there are three files that must be modified for every interface. The first is /etc/hostname.*, this is the file you create to designate the interface's name. The second file is /etc/hosts, here you resolve the IP to the interface name. Last is /etc/netmasks, this is where you define the netmask of the IP address.
--------------------------------------------------------------
Install Solaris OS and partition on Dell Box
The Dell Box has one IDE harddisk with about 120G capacity. Solaris identifies this disk to be c0d0.
During installation, fdisk partition it as
c0d0s0 which mount on /
c0d0s1 ----swap
c0d0s7 ----/export/home
c0d0s3,4,5,6 all not used but with 20G space. they will be used as the resources of the resource pool created by zpool.
----------------------------------------------------
create harddisk resource pool
(1)#zpool create spool c0d0s3
(2)#zpool add spool c0d0s4
(4)#zpool list
NAME SIZE USED AVAIL CAP HEALTH ALTROOT
spool 39G 196K 39.0G 0% ONLINE
-----------------------------------------------------------
set static IP for global zone:
refer to the doc on above comments....
To set static IP for global zone:
(1)create /etc/hosts file. so that:
#less hosts
#
# Internet host table
#
192.168.1.23 benchmark1
(2)create /etc/hostname.elxl0 so that:
#less hostname.elxl0
benchmark1
After these two files created, global zone are network enabled.
-----------------------------------------------------------------
setup static ip for zone benchmark2 (non-global zone)
After login into global zone,
if doing #ifconfig -a,
lo0: flags=2001000849
inet 127.0.0.1 netmask ff000000
elxl0: flags=1000843
inet 192.168.1.23 netmask ffffff00 broadcast 192.168.1.255
ether 0:1:2:12:67:53
#zonecfg -z benchmark2
=>add net
==>set ip=192.168.1.23
==>set physical=elxl0
...
and commit
After boot zone benchmark2, Now, do #ifconfig -a again:
lo0: flags=2001000849
inet 127.0.0.1 netmask ff000000
lo0:1: flags=2001000849
zone benchmark2
inet 127.0.0.1 netmask ff000000
elxl0: flags=1000843
inet 192.168.1.23 netmask ffffff00 broadcast 192.168.1.255
ether 0:1:2:12:67:53
elxl0:1: flags=1000843
zone benchmark2
inet 192.168.1.22 netmask ffffff00 broadcast 192.168.1.255
It indicates that non-global zone is already network enabled.
-----------------------------------------------
JBOSS setup
Copy jboss from zpeter4:
Including:
(1)/opt/jboss-4.0.4.GA
(2)/var/jboss
(3)/opt/bin/myip (this is used in jboss's run.sh file)
(4)if java security manager is included in the java parameter, make sure the corresponding policy file also there
---------------------------------------------------
JBOSS user
(1)user jboss must be created
(2)group jboss must be created
(3)home directory of user jboss must be /var/jboss
[ Show » ]
Peter Yang [16/May/07 12:27 PM] JBOSS user (1)user jboss must be created (2)group jboss must be created (3)home directory of user jboss must be /var/jboss
----------------------------------------------------------
Setup SMF for jboss:
(1)export smf script from zpeter4
#svccfg export jboss >/tmp/jboss.xml
and copy this exported file to new zone benchmark2.
(2)Copy /opt/lib/svc/method/svc-jboss from zpeter4 to benchmark2 zone in the corresponding directory
(3)import manifect file jboss.xml in benchmark2 zone.
/usr/sbin/svccfg -v import /tmp/jboss.xml
(4)enable jboss
#svcadm enable jboss
(5)monitoring the status of jboss service
#svcs -xv jboss
------------------------------------------------
how to remove service or edit manifest file
svcadm -v disable svc:/network/jboss
svccfg -v delete svc:/network/jboss
svccfg -v import /var/svc/manifest/jboss.xml
----------------------------------------------------
How to run NFS file server and mount NFS client
Problem:
For the development enviroment, there are four JBOSS servers. To enable the web log feature of the portal, it is required for all these JBOSS server to send their log files to a central NFS server, on which jbossportal server is running.
Parameters:
(1)JBOSS servers:
zpeter2, zpeter3, zpeter4 and benchmark2 (dell computer)
(2)NFS file server is running on storm, on which zroland3 zone is running. JBossPortal is running with zroland3 zone.
Steps:
(1)edit /etc/dfs/dfstab on storm to include following lines:
share -F nfs -o rw -d "zpeter2:/var/jboss/log" /zones/zroland3/root/nfsd/zpeter2
share -F nfs -o rw -d "zpeter3:/var/jboss/log" /zones/zroland3/root/nfsd/zpeter3
share -F nfs -o rw -d "zpeter4:/var/jboss/log" /zones/zroland3/root/nfsd/zpeter4
share -F nfs -o rw -d "benchmark2:/var/jboss/log" /zones/zroland3/root/nfsd/benchmark2
(2)make sure the mode of /zones/zroland3/root/nfsd/zpeter2, /zones/zroland3/root/nfsd/zpeter3, /zones/zroland3/root/nfsd/zpeter3 and /zones/zroland3/root/nfs/benchmark2 are 777. So that files can be written in these directories.
(3)restart NFS server
(4)on zone zpeter2, edit /etc/vfstab to include line:
storm:/zones/zroland3/root/nfsd/zpeter2 - /log nfs - yes rw
and do the same thing for zones zpeter3, zpeter4 and benchmark2
(5)restart these zones
Java VM Tuning - GC selection
GC collector selection:
(1)default collector(serial collector).
(2)throughput collector,which try to maximum CPU usage (minimize the CPU
usage by GC). But it could introduce big pause. So, this collector
cannot be used for RTS game server.
(3)Concurrent Low Pause Collector. On uniprocessor, this collector will
have worse performance than the default GC collector (serial collector).
On Two CPU machine, this collector will not pause the running
application, but it consume too much percentage of CPU. But for more CPU
(like 3 or 4), this collector is better than the default collector.
Currently, it is assumed that 2 processors machine will be used.
So, the default GC will be used.
The two main factors for JVM optimization are :
(1)Heap Size (-Xms and -Xmx)
(2)The second most influential knob is the proportion of the heap
dedicated to the young generation. By default, the young generation size
is controlled by NewRatio. For example, setting -XX:NewRatio=3 means
that the ratio between the young and tenured generation is 1:3. In other
words, the combined size of the eden and survivor spaces will be one
fourth of the total heap size. The bigger this ratio, the less pause.
However, more frequently the GC runs. This can be logged by another
command line options: -verbose:gc -XX:+PrintGCDetails.
If this ratio set to 15, you will see the GC runs very with less pause
each time.
Have no idea about the default value of this ratio.
Total Heap Size:
Since collections occur when generations fill up, throughput is
inversely proportional to the amount of memory available. Total
available memory is the most important factor affecting garbage
collection performance.
Unless having problems with pauses, try granting as much memory as
possible to the virtual machine. The default size (64MB) is often too
small.
To make sure the pause is not too big, adjust the NewRatio accordingly.
(1)default collector(serial collector).
(2)throughput collector,which try to maximum CPU usage (minimize the CPU
usage by GC). But it could introduce big pause. So, this collector
cannot be used for RTS game server.
(3)Concurrent Low Pause Collector. On uniprocessor, this collector will
have worse performance than the default GC collector (serial collector).
On Two CPU machine, this collector will not pause the running
application, but it consume too much percentage of CPU. But for more CPU
(like 3 or 4), this collector is better than the default collector.
Currently, it is assumed that 2 processors machine will be used.
So, the default GC will be used.
The two main factors for JVM optimization are :
(1)Heap Size (-Xms and -Xmx)
(2)The second most influential knob is the proportion of the heap
dedicated to the young generation. By default, the young generation size
is controlled by NewRatio. For example, setting -XX:NewRatio=3 means
that the ratio between the young and tenured generation is 1:3. In other
words, the combined size of the eden and survivor spaces will be one
fourth of the total heap size. The bigger this ratio, the less pause.
However, more frequently the GC runs. This can be logged by another
command line options: -verbose:gc -XX:+PrintGCDetails.
If this ratio set to 15, you will see the GC runs very with less pause
each time.
Have no idea about the default value of this ratio.
Total Heap Size:
Since collections occur when generations fill up, throughput is
inversely proportional to the amount of memory available. Total
available memory is the most important factor affecting garbage
collection performance.
Unless having problems with pauses, try granting as much memory as
possible to the virtual machine. The default size (64MB) is often too
small.
To make sure the pause is not too big, adjust the NewRatio accordingly.
Subscribe to:
Posts (Atom)