load-causing processes disappearing from “top” ps -o pcpu shows bogus numbers The Next CEO of Stack Overflowhow do you interpret output of top?How is my server hitting swap?How to understand the memory usage and load average in linux serverWhat could be causing load spikes on this EC2 instance?my webserver with 16GB ram shows all RAM as used, but is it really, see the 'top'memory leak? RHEL 5.5. RSS show ok, almost no free memory left, swap used heavilyLoad Average cpu linux serverMySQL on Linux out of memoryWebserver is being blocked by some IO processRandom High CPU load

Audio Conversion With ADS1243

What are the unusually-enlarged wing sections on this P-38 Lightning?

Scary film where a woman has vaginal teeth

Calculate the Mean mean of two numbers

Getting Stale Gas Out of a Gas Tank w/out Dropping the Tank

What would be the main consequences for a country leaving the WTO?

Is there a reasonable and studied concept of reduction between regular languages?

Do I need to write [sic] when including a quotation with a number less than 10 that isn't written out?

Purpose of level-shifter with same in and out voltages

Does Germany produce more waste than the US?

What flight has the highest ratio of timezone difference to flight time?

Is fine stranded wire ok for main supply line?

Yu-Gi-Oh cards in Python 3

Is it OK to decorate a log book cover?

How did Beeri the Hittite come up with naming his daughter Yehudit?

What steps are necessary to read a Modern SSD in Medieval Europe?

Is it correct to say moon starry nights?

how one can write a nice vector parser, something that does pgfvecparseA=B-C; D=E x F;

Towers in the ocean; How deep can they be built?

Why do we say 'Un seul M' and not 'Une seule M' even though M is a "consonne"

Can Sneak Attack be used when hitting with an improvised weapon?

Is there a difference between "Fahrstuhl" and "Aufzug"?

Help/tips for a first time writer?

Does the Idaho Potato Commission associate potato skins with healthy eating?



load-causing processes disappearing from “top” ps -o pcpu shows bogus numbers



The Next CEO of Stack Overflowhow do you interpret output of top?How is my server hitting swap?How to understand the memory usage and load average in linux serverWhat could be causing load spikes on this EC2 instance?my webserver with 16GB ram shows all RAM as used, but is it really, see the 'top'memory leak? RHEL 5.5. RSS show ok, almost no free memory left, swap used heavilyLoad Average cpu linux serverMySQL on Linux out of memoryWebserver is being blocked by some IO processRandom High CPU load










0















I administer a large number of servers, and I have this problem only with Ubuntu 10.04 LTS:
I run a server under normal load (say load average 3.0 on an 8-core server). The "top" command shows processes taking certain % of CPU that cause this load average: say



PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
11008 mysql 20 0 25.9g 22g 5496 S 67 76.0 643539:38 mysqld

ps -o pcpu,pid -p11008
%CPU PID
53.1 11008


, everything is consistent.



The all of the sudden, the process causing the load average disappears from "top", but the process continues to run normally (albeit with a slight performance decrease), and the system load average becomes somewhat higher. The output of ps -o pcpu becomes bogus:



# ps -o pcpu,pid -p11008
%CPU PID
317910278 1587


This happened to at least 5 different severs (different brand new IBM System X hardware), each running different software: one httpd 2.2, one mysqld 5.1, and one Twisted Python TCP servers. Each time the kernel was between 2.6.32-32-server and 2.6.32-40-server. I updated some machines to 2.6.32-41-server, and it has not happened on those yet, but the bug is rare (once every 60 days or so).



This is from an affected machine:



top - 10:39:06 up 73 days, 17:57, 3 users, load average: 6.62, 5.60, 5.34
Tasks: 207 total, 2 running, 205 sleeping, 0 stopped, 0 zombie
Cpu(s): 11.4%us, 18.0%sy, 0.0%ni, 66.3%id, 4.3%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 74341464k total, 71985004k used, 2356460k free, 236456k buffers
Swap: 3906552k total, 328k used, 3906224k free, 24838212k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
805 root 20 0 0 0 0 S 3 0.0 1493:09 fct0-worker
982 root 20 0 0 0 0 S 1 0.0 111:35.05 fioa-data-groom
914 root 20 0 0 0 0 S 0 0.0 884:42.71 fct1-worker
1068 root 20 0 19364 1496 1060 R 0 0.0 0:00.02 top


Nothing causing high load is showing on top, but I have two highly loaded mysqld instances on it, that suddenly show crazy %CPU:



#ps -o pcpu,pid,cmd -p1587
%CPU PID CMD
317713124 1587 /nail/encap/mysql-5.1.60/libexec/mysqld


and



#ps -o pcpu,pid,cmd -p1624
%CPU PID CMD
2802 1624 /nail/encap/mysql-5.1.60/libexec/mysqld


Here are the numbers from



 # cat /proc/1587/stat
1587 (mysqld) S 1212 1088 1088 0 -1 4202752 14307313 0 162 0 85773299069 4611685932654088833 0 0 20 0 52 0 3549 27255418880 5483524 18446744073709551615 4194304 11111617 140733749236976 140733749235984 8858659 0 552967 4102 26345 18446744073709551615 0 0 17 5 0 0 0 0 0


the 14th and 15th numbers according to



man proc 


are supposed to be



utime %lu Amount of time that this process has been scheduled in user mode, measured in clock ticks (divide by
sysconf(_SC_CLK_TCK). This includes guest time, guest_time (time spent running a virtual CPU, see
below), so that applications that are not aware of the guest time field do not lose that time from
their calculations.

stime %lu Amount of time that this process has been scheduled in kernel mode, measured in clock ticks (divide by
sysconf(_SC_CLK_TCK).


On a normal server, these numbers are advancing, every time I check the /proc/PID/stat.
On a buggy server, these numbers are stuck at a ridiculously high value like 4611685932654088833, and it's not changing.



Has anyone encountered this bug?










share|improve this question
















bumped to the homepage by Community yesterday


This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.















  • I have the same problem (almost) on two different servers. In both cases, the utime and stime in /proc/pid/stat are stuck at zero for all processes.

    – user147739
    Nov 30 '12 at 9:54















0















I administer a large number of servers, and I have this problem only with Ubuntu 10.04 LTS:
I run a server under normal load (say load average 3.0 on an 8-core server). The "top" command shows processes taking certain % of CPU that cause this load average: say



PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
11008 mysql 20 0 25.9g 22g 5496 S 67 76.0 643539:38 mysqld

ps -o pcpu,pid -p11008
%CPU PID
53.1 11008


, everything is consistent.



The all of the sudden, the process causing the load average disappears from "top", but the process continues to run normally (albeit with a slight performance decrease), and the system load average becomes somewhat higher. The output of ps -o pcpu becomes bogus:



# ps -o pcpu,pid -p11008
%CPU PID
317910278 1587


This happened to at least 5 different severs (different brand new IBM System X hardware), each running different software: one httpd 2.2, one mysqld 5.1, and one Twisted Python TCP servers. Each time the kernel was between 2.6.32-32-server and 2.6.32-40-server. I updated some machines to 2.6.32-41-server, and it has not happened on those yet, but the bug is rare (once every 60 days or so).



This is from an affected machine:



top - 10:39:06 up 73 days, 17:57, 3 users, load average: 6.62, 5.60, 5.34
Tasks: 207 total, 2 running, 205 sleeping, 0 stopped, 0 zombie
Cpu(s): 11.4%us, 18.0%sy, 0.0%ni, 66.3%id, 4.3%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 74341464k total, 71985004k used, 2356460k free, 236456k buffers
Swap: 3906552k total, 328k used, 3906224k free, 24838212k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
805 root 20 0 0 0 0 S 3 0.0 1493:09 fct0-worker
982 root 20 0 0 0 0 S 1 0.0 111:35.05 fioa-data-groom
914 root 20 0 0 0 0 S 0 0.0 884:42.71 fct1-worker
1068 root 20 0 19364 1496 1060 R 0 0.0 0:00.02 top


Nothing causing high load is showing on top, but I have two highly loaded mysqld instances on it, that suddenly show crazy %CPU:



#ps -o pcpu,pid,cmd -p1587
%CPU PID CMD
317713124 1587 /nail/encap/mysql-5.1.60/libexec/mysqld


and



#ps -o pcpu,pid,cmd -p1624
%CPU PID CMD
2802 1624 /nail/encap/mysql-5.1.60/libexec/mysqld


Here are the numbers from



 # cat /proc/1587/stat
1587 (mysqld) S 1212 1088 1088 0 -1 4202752 14307313 0 162 0 85773299069 4611685932654088833 0 0 20 0 52 0 3549 27255418880 5483524 18446744073709551615 4194304 11111617 140733749236976 140733749235984 8858659 0 552967 4102 26345 18446744073709551615 0 0 17 5 0 0 0 0 0


the 14th and 15th numbers according to



man proc 


are supposed to be



utime %lu Amount of time that this process has been scheduled in user mode, measured in clock ticks (divide by
sysconf(_SC_CLK_TCK). This includes guest time, guest_time (time spent running a virtual CPU, see
below), so that applications that are not aware of the guest time field do not lose that time from
their calculations.

stime %lu Amount of time that this process has been scheduled in kernel mode, measured in clock ticks (divide by
sysconf(_SC_CLK_TCK).


On a normal server, these numbers are advancing, every time I check the /proc/PID/stat.
On a buggy server, these numbers are stuck at a ridiculously high value like 4611685932654088833, and it's not changing.



Has anyone encountered this bug?










share|improve this question
















bumped to the homepage by Community yesterday


This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.















  • I have the same problem (almost) on two different servers. In both cases, the utime and stime in /proc/pid/stat are stuck at zero for all processes.

    – user147739
    Nov 30 '12 at 9:54













0












0








0








I administer a large number of servers, and I have this problem only with Ubuntu 10.04 LTS:
I run a server under normal load (say load average 3.0 on an 8-core server). The "top" command shows processes taking certain % of CPU that cause this load average: say



PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
11008 mysql 20 0 25.9g 22g 5496 S 67 76.0 643539:38 mysqld

ps -o pcpu,pid -p11008
%CPU PID
53.1 11008


, everything is consistent.



The all of the sudden, the process causing the load average disappears from "top", but the process continues to run normally (albeit with a slight performance decrease), and the system load average becomes somewhat higher. The output of ps -o pcpu becomes bogus:



# ps -o pcpu,pid -p11008
%CPU PID
317910278 1587


This happened to at least 5 different severs (different brand new IBM System X hardware), each running different software: one httpd 2.2, one mysqld 5.1, and one Twisted Python TCP servers. Each time the kernel was between 2.6.32-32-server and 2.6.32-40-server. I updated some machines to 2.6.32-41-server, and it has not happened on those yet, but the bug is rare (once every 60 days or so).



This is from an affected machine:



top - 10:39:06 up 73 days, 17:57, 3 users, load average: 6.62, 5.60, 5.34
Tasks: 207 total, 2 running, 205 sleeping, 0 stopped, 0 zombie
Cpu(s): 11.4%us, 18.0%sy, 0.0%ni, 66.3%id, 4.3%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 74341464k total, 71985004k used, 2356460k free, 236456k buffers
Swap: 3906552k total, 328k used, 3906224k free, 24838212k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
805 root 20 0 0 0 0 S 3 0.0 1493:09 fct0-worker
982 root 20 0 0 0 0 S 1 0.0 111:35.05 fioa-data-groom
914 root 20 0 0 0 0 S 0 0.0 884:42.71 fct1-worker
1068 root 20 0 19364 1496 1060 R 0 0.0 0:00.02 top


Nothing causing high load is showing on top, but I have two highly loaded mysqld instances on it, that suddenly show crazy %CPU:



#ps -o pcpu,pid,cmd -p1587
%CPU PID CMD
317713124 1587 /nail/encap/mysql-5.1.60/libexec/mysqld


and



#ps -o pcpu,pid,cmd -p1624
%CPU PID CMD
2802 1624 /nail/encap/mysql-5.1.60/libexec/mysqld


Here are the numbers from



 # cat /proc/1587/stat
1587 (mysqld) S 1212 1088 1088 0 -1 4202752 14307313 0 162 0 85773299069 4611685932654088833 0 0 20 0 52 0 3549 27255418880 5483524 18446744073709551615 4194304 11111617 140733749236976 140733749235984 8858659 0 552967 4102 26345 18446744073709551615 0 0 17 5 0 0 0 0 0


the 14th and 15th numbers according to



man proc 


are supposed to be



utime %lu Amount of time that this process has been scheduled in user mode, measured in clock ticks (divide by
sysconf(_SC_CLK_TCK). This includes guest time, guest_time (time spent running a virtual CPU, see
below), so that applications that are not aware of the guest time field do not lose that time from
their calculations.

stime %lu Amount of time that this process has been scheduled in kernel mode, measured in clock ticks (divide by
sysconf(_SC_CLK_TCK).


On a normal server, these numbers are advancing, every time I check the /proc/PID/stat.
On a buggy server, these numbers are stuck at a ridiculously high value like 4611685932654088833, and it's not changing.



Has anyone encountered this bug?










share|improve this question
















I administer a large number of servers, and I have this problem only with Ubuntu 10.04 LTS:
I run a server under normal load (say load average 3.0 on an 8-core server). The "top" command shows processes taking certain % of CPU that cause this load average: say



PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
11008 mysql 20 0 25.9g 22g 5496 S 67 76.0 643539:38 mysqld

ps -o pcpu,pid -p11008
%CPU PID
53.1 11008


, everything is consistent.



The all of the sudden, the process causing the load average disappears from "top", but the process continues to run normally (albeit with a slight performance decrease), and the system load average becomes somewhat higher. The output of ps -o pcpu becomes bogus:



# ps -o pcpu,pid -p11008
%CPU PID
317910278 1587


This happened to at least 5 different severs (different brand new IBM System X hardware), each running different software: one httpd 2.2, one mysqld 5.1, and one Twisted Python TCP servers. Each time the kernel was between 2.6.32-32-server and 2.6.32-40-server. I updated some machines to 2.6.32-41-server, and it has not happened on those yet, but the bug is rare (once every 60 days or so).



This is from an affected machine:



top - 10:39:06 up 73 days, 17:57, 3 users, load average: 6.62, 5.60, 5.34
Tasks: 207 total, 2 running, 205 sleeping, 0 stopped, 0 zombie
Cpu(s): 11.4%us, 18.0%sy, 0.0%ni, 66.3%id, 4.3%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 74341464k total, 71985004k used, 2356460k free, 236456k buffers
Swap: 3906552k total, 328k used, 3906224k free, 24838212k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
805 root 20 0 0 0 0 S 3 0.0 1493:09 fct0-worker
982 root 20 0 0 0 0 S 1 0.0 111:35.05 fioa-data-groom
914 root 20 0 0 0 0 S 0 0.0 884:42.71 fct1-worker
1068 root 20 0 19364 1496 1060 R 0 0.0 0:00.02 top


Nothing causing high load is showing on top, but I have two highly loaded mysqld instances on it, that suddenly show crazy %CPU:



#ps -o pcpu,pid,cmd -p1587
%CPU PID CMD
317713124 1587 /nail/encap/mysql-5.1.60/libexec/mysqld


and



#ps -o pcpu,pid,cmd -p1624
%CPU PID CMD
2802 1624 /nail/encap/mysql-5.1.60/libexec/mysqld


Here are the numbers from



 # cat /proc/1587/stat
1587 (mysqld) S 1212 1088 1088 0 -1 4202752 14307313 0 162 0 85773299069 4611685932654088833 0 0 20 0 52 0 3549 27255418880 5483524 18446744073709551615 4194304 11111617 140733749236976 140733749235984 8858659 0 552967 4102 26345 18446744073709551615 0 0 17 5 0 0 0 0 0


the 14th and 15th numbers according to



man proc 


are supposed to be



utime %lu Amount of time that this process has been scheduled in user mode, measured in clock ticks (divide by
sysconf(_SC_CLK_TCK). This includes guest time, guest_time (time spent running a virtual CPU, see
below), so that applications that are not aware of the guest time field do not lose that time from
their calculations.

stime %lu Amount of time that this process has been scheduled in kernel mode, measured in clock ticks (divide by
sysconf(_SC_CLK_TCK).


On a normal server, these numbers are advancing, every time I check the /proc/PID/stat.
On a buggy server, these numbers are stuck at a ridiculously high value like 4611685932654088833, and it's not changing.



Has anyone encountered this bug?







linux ubuntu top ps






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Jul 10 '12 at 18:34







Alec Matusis

















asked Jul 10 '12 at 17:57









Alec MatusisAlec Matusis

15116




15116





bumped to the homepage by Community yesterday


This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.







bumped to the homepage by Community yesterday


This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.














  • I have the same problem (almost) on two different servers. In both cases, the utime and stime in /proc/pid/stat are stuck at zero for all processes.

    – user147739
    Nov 30 '12 at 9:54

















  • I have the same problem (almost) on two different servers. In both cases, the utime and stime in /proc/pid/stat are stuck at zero for all processes.

    – user147739
    Nov 30 '12 at 9:54
















I have the same problem (almost) on two different servers. In both cases, the utime and stime in /proc/pid/stat are stuck at zero for all processes.

– user147739
Nov 30 '12 at 9:54





I have the same problem (almost) on two different servers. In both cases, the utime and stime in /proc/pid/stat are stuck at zero for all processes.

– user147739
Nov 30 '12 at 9:54










1 Answer
1






active

oldest

votes


















0














I guess this might be a bug in procps package instead of kernel. Not seen the bug you described, but similar bugs over the years in various distros, yes.



If this is about procps, is there a bugfix available for Ubuntu 10.04 LTS? No idea, have not used it in a long, long time, and even the last time was in a galaxy far, far away...






share|improve this answer























  • I suspect a kernel bug, since the 13th and 14th numbers (utime and stime) in /proc/<PID>/stat are very strange: they are larger by 5 orders of magnitude than on a normal server, and not advancing, while the process is running.

    – Alec Matusis
    Jul 10 '12 at 18:22











Your Answer








StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "2"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);













draft saved

draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f406489%2fload-causing-processes-disappearing-from-top-ps-o-pcpu-shows-bogus-numbers%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









0














I guess this might be a bug in procps package instead of kernel. Not seen the bug you described, but similar bugs over the years in various distros, yes.



If this is about procps, is there a bugfix available for Ubuntu 10.04 LTS? No idea, have not used it in a long, long time, and even the last time was in a galaxy far, far away...






share|improve this answer























  • I suspect a kernel bug, since the 13th and 14th numbers (utime and stime) in /proc/<PID>/stat are very strange: they are larger by 5 orders of magnitude than on a normal server, and not advancing, while the process is running.

    – Alec Matusis
    Jul 10 '12 at 18:22















0














I guess this might be a bug in procps package instead of kernel. Not seen the bug you described, but similar bugs over the years in various distros, yes.



If this is about procps, is there a bugfix available for Ubuntu 10.04 LTS? No idea, have not used it in a long, long time, and even the last time was in a galaxy far, far away...






share|improve this answer























  • I suspect a kernel bug, since the 13th and 14th numbers (utime and stime) in /proc/<PID>/stat are very strange: they are larger by 5 orders of magnitude than on a normal server, and not advancing, while the process is running.

    – Alec Matusis
    Jul 10 '12 at 18:22













0












0








0







I guess this might be a bug in procps package instead of kernel. Not seen the bug you described, but similar bugs over the years in various distros, yes.



If this is about procps, is there a bugfix available for Ubuntu 10.04 LTS? No idea, have not used it in a long, long time, and even the last time was in a galaxy far, far away...






share|improve this answer













I guess this might be a bug in procps package instead of kernel. Not seen the bug you described, but similar bugs over the years in various distros, yes.



If this is about procps, is there a bugfix available for Ubuntu 10.04 LTS? No idea, have not used it in a long, long time, and even the last time was in a galaxy far, far away...







share|improve this answer












share|improve this answer



share|improve this answer










answered Jul 10 '12 at 18:09









Janne PikkarainenJanne Pikkarainen

28.4k34268




28.4k34268












  • I suspect a kernel bug, since the 13th and 14th numbers (utime and stime) in /proc/<PID>/stat are very strange: they are larger by 5 orders of magnitude than on a normal server, and not advancing, while the process is running.

    – Alec Matusis
    Jul 10 '12 at 18:22

















  • I suspect a kernel bug, since the 13th and 14th numbers (utime and stime) in /proc/<PID>/stat are very strange: they are larger by 5 orders of magnitude than on a normal server, and not advancing, while the process is running.

    – Alec Matusis
    Jul 10 '12 at 18:22
















I suspect a kernel bug, since the 13th and 14th numbers (utime and stime) in /proc/<PID>/stat are very strange: they are larger by 5 orders of magnitude than on a normal server, and not advancing, while the process is running.

– Alec Matusis
Jul 10 '12 at 18:22





I suspect a kernel bug, since the 13th and 14th numbers (utime and stime) in /proc/<PID>/stat are very strange: they are larger by 5 orders of magnitude than on a normal server, and not advancing, while the process is running.

– Alec Matusis
Jul 10 '12 at 18:22

















draft saved

draft discarded
















































Thanks for contributing an answer to Server Fault!


  • Please be sure to answer the question. Provide details and share your research!

But avoid


  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f406489%2fload-causing-processes-disappearing-from-top-ps-o-pcpu-shows-bogus-numbers%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Club Baloncesto Breogán Índice Historia | Pavillón | Nome | O Breogán na cultura popular | Xogadores | Adestradores | Presidentes | Palmarés | Historial | Líderes | Notas | Véxase tamén | Menú de navegacióncbbreogan.galCadroGuía oficial da ACB 2009-10, páxina 201Guía oficial ACB 1992, páxina 183. Editorial DB.É de 6.500 espectadores sentados axeitándose á última normativa"Estudiantes Junior, entre as mellores canteiras"o orixinalHemeroteca El Mundo Deportivo, 16 setembro de 1970, páxina 12Historia do BreogánAlfredo Pérez, o último canoneiroHistoria C.B. BreogánHemeroteca de El Mundo DeportivoJimmy Wright, norteamericano do Breogán deixará Lugo por ameazas de morteResultados de Breogán en 1986-87Resultados de Breogán en 1990-91Ficha de Velimir Perasović en acb.comResultados de Breogán en 1994-95Breogán arrasa al Barça. "El Mundo Deportivo", 27 de setembro de 1999, páxina 58CB Breogán - FC BarcelonaA FEB invita a participar nunha nova Liga EuropeaCharlie Bell na prensa estatalMáximos anotadores 2005Tempada 2005-06 : Tódolos Xogadores da Xornada""Non quero pensar nunha man negra, mais pregúntome que está a pasar""o orixinalRaúl López, orgulloso dos xogadores, presume da boa saúde económica do BreogánJulio González confirma que cesa como presidente del BreogánHomenaxe a Lisardo GómezA tempada do rexurdimento celesteEntrevista a Lisardo GómezEl COB dinamita el Pazo para forzar el quinto (69-73)Cafés Candelas, patrocinador del CB Breogán"Suso Lázare, novo presidente do Breogán"o orixinalCafés Candelas Breogán firma el mayor triunfo de la historiaEl Breogán realizará 17 homenajes por su cincuenta aniversario"O Breogán honra ao seu fundador e primeiro presidente"o orixinalMiguel Giao recibiu a homenaxe do PazoHomenaxe aos primeiros gladiadores celestesO home que nos amosa como ver o Breo co corazónTita Franco será homenaxeada polos #50anosdeBreoJulio Vila recibirá unha homenaxe in memoriam polos #50anosdeBreo"O Breogán homenaxeará aos seus aboados máis veteráns"Pechada ovación a «Capi» Sanmartín e Ricardo «Corazón de González»Homenaxe por décadas de informaciónPaco García volve ao Pazo con motivo do 50 aniversario"Resultados y clasificaciones""O Cafés Candelas Breogán, campión da Copa Princesa""O Cafés Candelas Breogán, equipo ACB"C.B. Breogán"Proxecto social"o orixinal"Centros asociados"o orixinalFicha en imdb.comMario Camus trata la recuperación del amor en 'La vieja música', su última película"Páxina web oficial""Club Baloncesto Breogán""C. B. Breogán S.A.D."eehttp://www.fegaba.com

Vilaño, A Laracha Índice Patrimonio | Lugares e parroquias | Véxase tamén | Menú de navegación43°14′52″N 8°36′03″O / 43.24775, -8.60070

Cegueira Índice Epidemioloxía | Deficiencia visual | Tipos de cegueira | Principais causas de cegueira | Tratamento | Técnicas de adaptación e axudas | Vida dos cegos | Primeiros auxilios | Crenzas respecto das persoas cegas | Crenzas das persoas cegas | O neno deficiente visual | Aspectos psicolóxicos da cegueira | Notas | Véxase tamén | Menú de navegación54.054.154.436928256blindnessDicionario da Real Academia GalegaPortal das Palabras"International Standards: Visual Standards — Aspects and Ranges of Vision Loss with Emphasis on Population Surveys.""Visual impairment and blindness""Presentan un plan para previr a cegueira"o orixinalACCDV Associació Catalana de Cecs i Disminuïts Visuals - PMFTrachoma"Effect of gene therapy on visual function in Leber's congenital amaurosis"1844137110.1056/NEJMoa0802268Cans guía - os mellores amigos dos cegosArquivadoEscola de cans guía para cegos en Mortágua, PortugalArquivado"Tecnología para ciegos y deficientes visuales. Recopilación de recursos gratuitos en la Red""Colorino""‘COL.diesis’, escuchar los sonidos del color""COL.diesis: Transforming Colour into Melody and Implementing the Result in a Colour Sensor Device"o orixinal"Sistema de desarrollo de sinestesia color-sonido para invidentes utilizando un protocolo de audio""Enseñanza táctil - geometría y color. Juegos didácticos para niños ciegos y videntes""Sistema Constanz"L'ocupació laboral dels cecs a l'Estat espanyol està pràcticament equiparada a la de les persones amb visió, entrevista amb Pedro ZuritaONCE (Organización Nacional de Cegos de España)Prevención da cegueiraDescrición de deficiencias visuais (Disc@pnet)Braillín, un boneco atractivo para calquera neno, con ou sen discapacidade, que permite familiarizarse co sistema de escritura e lectura brailleAxudas Técnicas36838ID00897494007150-90057129528256DOID:1432HP:0000618D001766C10.597.751.941.162C97109C0155020