Large ibdata file in MySQL I am having MySQL database with all my tables as InnoDB with file_per_table config on. But Still I m seeing huge ibdata file ( ~50GB). All tables are having .ibd file as well. This is a machine I have created by taking dump and loading. What is a reason for this.
You probably have lots of large transactions or one really big transaction.
Take a look at Vadim Tkachenko's Pictorial Representation of InnoDB

If you look inside the system table (ibdata1), you see rollback segments and undo logs.
When a rollback segment rolls back a transaction, it has to use the MVCC information it stockpiled in the undo space. That's where most of the growth occurs. Percona mentioned this back on Jun 10, 2010 (Reasons for run-away main Innodb Tablespace)
I have discussed this before

Apr 23, 2013 : How can Innodb ibdata1 file grows by 5X even with innodb_file_per_table set?
Mar 31, 2014 : mysql directory grow to 246G after one query, which failed due to table is full
Jun 16, 2014 : MySQL Index creation failing on table is full

UPDATE 2015-03-22 15:00 EDT
If you are convinced the data dictionary is the cause, there is only one sure way you can verify this.

STEP 01) Get another DB Server (Dev or Test)
STEP 02) Install MySQL on it
STEP 03) mysqldump the schema-only (using --no-data)
STEP 04) load the schema-only dump into the empty database
STEP 05) run ls -l /var/lib/mysql/ibdata1 | awk '{print $5}'

The number that comes out will be the size will be the size of ibdata1 with just data dictionary entries for the current list of tables, but with no data in them.
In your last comment, you said

So open transaction doesnot seem to be right reason. We use to create some 200-300 table on daily basis (by our ETL tool) and drop them after some processing periodically ( drop some 2k-5k tables once in 2-3weeks), could this attribute to the big file ?

You could be right for same reason: Just like rollback segments and the undo space have no provision for reclaiming unused diskspace for the OS, dropping tables and creating new ones would likewise have no provision for reclaiming unused diskspace for the OS.
To prove that, you would have to use that new server with all tables but no data. Then, perform the same dropping and creating of tables every week. If the ibdata1 grows just for doing that, then you have proven undeniably that dropping and creating tables alone can grow ibdata1 with innodb_file_per_table enabled.
If you want to cleanup ibdata1, please see my posts

Sep 26, 2012 : How do I shrink the innodb file ibdata1 without dumping all databases?
(on why you have to dump all data, remove ibdatat1, and create a new ibdata1)
Oct 29, 2010 : Howto: Clean a mysql InnoDB storage engine? (on how to actually do this)

GIVE IT A TRY!!!