To answer your first question, 4GB isn't a big dump file. Sizes orders of magnitude larger are common, so there's something wrong with the database, the file or your MySQL configuration.
1. To test the dump file itself, run the dump file against another instance of mysql.
2. The database: It's simple to rule out the database. First, check the mysql error log for errors that occurred during the import. If nothing's there, edit the dump file to have it create and change a new db, and run the import again. If it runs without a hitch, you'll need to either check very db object, or if the dump is a complete backup then drop the old dn completely, undo your edits to the dump file, then let the dump file try to recreate and populate the db.
3. If you got this far without finding the problem, you have a configuration problem, please ...
(i) post the result of ...
select engine,data,indexes,total
from (
select
ifnull(engine,'TOTALS') as engine,
concat(data,' GB') as data,
concat(indexes,' GB') as indexes,
concat(tot,' GB') as total,
if(engine is null,-1,tot) as ord
from (
select
engine,
round( sum(data_length)/1024/1024/1024, 2 ) as data,
round( sum(index_length)/1024/1024/1024, 2 ) as indexes,
round( sum(data_length+index_length)/1024/1024/1024, 2 ) as tot
from information_schema.tables
where engine is not null and engine not in('information_schema','performance_schema')
group by engine with rollup
) sums
) list
order by list.ord desc;
(ii) post the results of running these queries in the mysql client program ...
show variables;
show global status;
(iii) if this is Linux, post the result of ...
free -m
... otherwise just tell us how much RAM the machine has, and whether there is any swap activity during the import.